6.1 When describing a system, explain why you may have to start the design of the system architecture before the requirements specification is complete.

You may have to design the system architecture before the requirements specification is complete because the architecture has a significant impact on the non-functional requirements and can also influence the functional requirements as well. Specifically, in order to demonstrate to stakeholders that an application will meet its performance requirements a project manager or system architect may have to show how the architecture will aid in accomplishing this goal. According to Sommerville the components affect the requirements and therefore an architecture that explains the components and their relationships may aid in the determination of the requirements. the architectural design serves as basis for the description. Since it involves identifying major system components, sub systems, and their communications, it will be easier in the description to specify which one goes to which sub systems. And when subsystems are already made, it will be easier to determine what components are needed by hardware manufacturers. "lso, the architectural design provides a model for system costing. The architecture may have to be designed before specifications are written to provide a means of structuring the specification and developing different subsystem specifications concurrently, to allow manufacture of hardware by subcontractors and to provide a model for system costing. The architecture have to be designed before specifications are written, because to provide a means of structuring  the specification and developing different sub-system specifications concurrently to allow manufacture of hardware by sub-contractors and to provide a model for system costing. Writing specification for the whole system might bring great complexity and it is difficult to formulate it. Therefore, it is easier to divide the system into simpler subsystems and define their specification and it will save you the hassle of defining specification and put it into the respective subsystem. Hence we can concurrently develop subsystems and the specifications to be readily into the implementation stage.

6.2 You have been asked to prepare and deliver a presentation to a non-technical manager to justify the hiring of a system architect for a new project. Write the points setting out the key points in your presentation in which you explain the importance of software architecture.

Registry System which contains Information extraction System, Information Storage System and Information evaluation System provides the registry function of the all system. In that, administrator can manipulate the information about the employee. For example, store,
delete, and add. Therefore, we have Control System. The decision making System used to decide whether a certain employee would be hired or not. The System Architect is charged with leading a technical team of software engineers in the design and development of transactional Web-based applications. MICROS-Retail provides both the strategic expertise and technical solutions that yield real business results for clients such as Crate and Barrel, Eddie Bauer, Godiva Chocolatier, La-Z-Boy, Meijer, The Swiss Colony and Whirlpool. System Architects are excellent communicators who are able to lead complicated design efforts with technical staff as well as being able to work with non-technical clients and project managers by translating business issues into technical solutions. The System Architect should have at least 9 years of experience. Responsibilities: Technical team leadership Assist in project management Application design Technical specification documentation Communicate technical issues to project managers and clients Configuration and prototyping of new systems Delegate work to others Demonstrated technical leadership experience 8+ years experience in object-oriented development Very strong experience in: J2EE architecture, OO design patterns, Web application servers (Websphere, Tomcat, Weblogic), relational databases (Oracle, SQL Server, DB/2) Experience in Microsoft .

6.3 performance and security may pose to be conflicting non-functional requirements when architecting software systems. Make an argument in support of this statement.

When a customer requests that we build a new system, the customer has some notion of what the system should do.  Often, the customer wants to automate a manual task, such as paying bills electronically rather than with hand-written checks. Sometimes, the customer wants to enhance or extend a current manual or automated system. For example, a telephone billing system that had charged customers for only local telephone service and long-distance calls may be updated to bill for call forwarding, call waiting, and other new features. More and more frequently, a customer wants products that do things that have never been done before:  tailoring electronic news to a user’s interests, changing the shape of an airplane wing in midflight, or monitoring a diabetic’s blood sugar and automatically controlling insulin dosage. No matter whether its functionality is old or new, a proposed software system has a purpose, usually expressed in terms of goals or desired behavior.However, for problems where the requirements are uncertain, it can be cumbersome to employ a heavy process and have to update the models with every change to the requirements.  As an alternative approach, agile methods gather and implement the requirements in increments.  The initial release implements the most essential requirements, as defined by the stakeholders’ business goals. As new requirements emerge, with use of the system or with better understanding of the problem, they are implemented in subsequent releases of the system.  This incremental development allows for “early and continuous delivery of valuable software” (Beck et al. 2001) and accommodates emergent and late-breaking requirements.Clients, who are the ones paying for the software to be developed:  By paying for the development, the clients are, is some sense, the ultimate stakeholders, and have final say in what the product does Customers, who buy the software after it is developed: Sometimes the customer and the user are the same; other times, the customer is a business manager who is interested in improving the productivity of her employees.  We have to understand the customers’ needs well enough to build a product that they will buy and find useful. Users, who are familiar with the current system and will use the future system:  These are the experts on how the current system works, which features are the most useful, and which aspects of the system need improving.  We may want to consult also with special-interest groups of users, such as users with disabilities, people who are unfamiliar with or uncomfortable using computers, expert users, and so on, to understand their particular needs.