(CST309 MANAGEMENT OF SOFTWARE SYSTEMS Module 2: Requirement Analysis and Design (8 hours) Functional and non-functional requirements, Requirements engineering processes. Requirements elicitation, Requirements validation, Requirements change, Traceability Matrix. Developing use cases, Software Requirements Specification Template, Personas, Scenarios, User stories, Feature identification. Design concepts - Design within the context of software engineering, Design Process, Design concepts, Design Model. Architectural Design - Software Architecture, Architectural Styles, Architectural considerations, Architectural Design Component level design - What is a component?, Designing Class-Based Components, Conducting Component level design, Component level design for web-apps. Template of a Design Document as per “IEEE Std 1016-2009 IEEE Standard for Information Technology Systems Design Software Design Descriptions”. Case study: The Ariane 5 launcher failure, * * * ‘The requirements are the descriptions of the services that a system should provide and the constraints operation. These requirements reflect the needs of customers for a system. ‘The process of finding out, analysing, documenting and checking these services and constraints is called requirements engineering (RE) Some of the problems that arise during the requirements engineering process are a result of failing to make a clear separation between these different levels of description. 1. User requirements are what services the system is expected to provide to system users and the constraints under which it must operate. tem requirements are more detailed descriptions of the software and operational constraints. tem’s functions, services, Figure 4.2 shows the types of readers of the user and system requirements. The readers of the user requirements are not usually concerned with how the system will be implemented and may be managers who are not interested in the detailed facilities of the system. The readers of the system requirements need to know more precisely what the system will do because they are concerned with how it will support the business processes or because they are involved in the system implementation For example, system stakeholders for the Mentcare system include: 1. Patients whose information is recorded in the system and relatives of these patients, Doctors who are responsible for assessing and treating patients. Nurses who coordinate the consultations with doctors and administer some treatments. Medical receptionists who manage patients’ appointments, Bee Requirements engineering is usually presented as the first stage of the software engineering process. However, some understanding of the system requirements may have to be developed before a decision is made to go ahead with the procurement or development of a system. 1.1 Functional requirements ‘The functional requirements for a system describe what the system should do. These requirements depend on the type of software being developed, the expected users of the software, and the general approach taken by the organization when writing requirements.1. Functional and non-functional Client managers requirements System architects Software system requirements are often classified as functional or non-fune IL requirements: ‘system end-users Client engineers system architects Software developers Functional system requirements expand the user requirements and are written for system developers. They should describe the system functions, their inputs and outputs, and exceptions in detail. For example, here are examples of functional requirements for the Menteare system, used to maintain information about patients receiving treatment for mental health problems: 1. A user shall be able to search the appointments lists for all clinics. 2. The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day. Imprecision in the requirements specification can lead to disputes between customers and software developers. 1.2 Non-functional requirements Non-functional requirements are requirements that are not directly concerned with the specific services delivered by the system to its users. These requirements usually specify or constrain characteristics of the system as a whole. They may relate to system properties such as reliability, response time, and memory use, Non-functional requirements are often more eritical than individual functional requirements. Failing to meet a non-functional requirement can mean that the whole system is unusable. 1, Product requirements These requirements specify or constrain the runtime behaviour of the software Examples: how fast the system must execute and how much memory it requires; 2. Organizational requirements These requirements are broad system requirements derived from policies and procedures in the customer's and developer's organizations. Examples: operational process requirements that define how the system will be used; programming language and the standards to be used. 3. External requirements This broad heading covers all requirements that are derived from factors external to the system and its development process. Example: Regulatory requirements that set out what must be done for the system to be approved for use by a regulator. 2. Requirements engineering processes Requirements engineering involves three key activities. These are discovering requirements by interacting with stakeholders (clicitation and analysis); converting these requirements into a standard form (specification); and checking that the requirements actually define the system that the ct wants (validation). This is an iterative process in which the activit interleaved Figure 46 shows this interleaving: The output of the RE process is a system requirements document The amount of time and effort devoted to each activity depends on the stages of the overall process, the type of system, and the budget.Non-functional requirements Product ‘Organizational Extemal requirements requirements ‘requirements Efficiency Dependability Security Regulatory Ethical requitements | | requirements | requirements ‘requirements Usability Environmental |) { Operational |) { Development Legislative requirements. fequirements | requirements || requirements requirements Performance Space ‘Accounting |) | Safety/security fequirements | requirements requirements | | requirements Aequrments specication ‘Stem requirements specication and modoling User requirements specication ‘Business quirements specication Requirements — ‘elicitation ea tation ‘validation requirements ‘ication Figure 46 A spialview ofthe requirements System requirements fonginosing process ‘document 3, Requirements elicitation The aims of the requirements elicitation process are to understand the work that stakeholders do and how they might use a new system to help support that work. Dur 1g requirements elicitation,software engineers work with stakeholders to find out about the application domain, work activities, the services and system features that stakeholders want, the required performance of the syster hardware constraints, and so on. This is a difficult process for several reasons: 1, Stakeholders often don't know what they want from a computer system except in the most general terms; they may find it difficult to articulate what they want the system to do; Stakeholders in a system naturally express requirements in their own terms and with implicit knowledge of their own work. 2. Different stakeholders, with diverse requirements, may express their requirements in different ways. 8. Political factors may influence the requirements of a system 4. ‘The economic and business environment in which the analysis takes place is dynamic. New requirements may emerge from new stakeholders who were not originally consulted. Process model of the elicitation and analysis process is shown in Figure 4.7. “The process activities are: 1. Requirements discovery and understanding This is the process of interacting with stakeholders of the system to discover their requirements. Domain requirements from stakeholders and documentation are also discovered during this activity. 2. Requirements classification and organization This activity takes the unstructured collection of requirements, groups related requirements and organizes them into coherent clusters. 3. Requirements prioritization and negotiation Inevitably, when multiple stakeholders are involved, requirements will conflict. This activity is concerned with prioritizing requirements and finding and resolving requirements conflicts through negotiation 4. Requirements documentation The requirements are documented and input into the next round of the spiral. An early draft of the software requirements documents may be produced at this stage, or the requirements may simply be maintained informally on whiteboards, wikis, or other shared spaces. To simplify the analysis of requirements, it is helpful to organize and group the stakeholder information. One way of doing so is to consider each stakeholder group to be a viewpoint and to collect all requirements from that group into the viewpoint. At the requirements documentation stage, itis important that you use simple language and diagra to deseribe the requirements. This makes it possible for stakeholders to understand and comment on these requirements. 3.1 Requirements elicitation techniques Requirements elicitation involves meeting with stakeholders of different kinds to discover information about the proposed system, You need to spend time understanding how people work, what they produce, how they use other systems, and how they may need to change to accommodate anew system. ‘There are two fundamental approaches to requirements elicitation 1. Interviewing, where you talk to people about what they do. 2. Observation or ethnography, where you watch people doing their job to see what artefacts they use, how they use them, and so on.discovery and understanding classification and organization negotiation You should use a mix of interviewing and observation to collect information and, from that, you derive the requirements, which are then the basis for further discussions, 3.1.1 Interviewing Formal or informal interviews with system stakeholders are part of most requirements engineering processes. In these interviews, the requirements engineering team puts questions to stakeholders about the system that they currently use and the system to be developed. Requirements are derived from the answers to these questions. Interviews may be of two types: 1. Closed interviews, where the stakeholder answers a predefined set of questions. 2. Open interviews, in which there is no predefined agenda. The team explores a range of issues with system stakeholders and hence develops a better understanding of their needs. In practice, interviews with stakeholders are normally a mixture of both of these. Interviews are good for getting an overall understanding of what stakeholders do, how they might interact with the new system, and the difficulties that they face with current system Eliciting domain knowledge through interviews can be difficult, for two reasons: 1. All application specialists use jargon specific to their area of work. They normally use words in a precise and subtle way that requirements engineers may misunderstand. 2. Some domain knowledge is so familiar to stakeholders that they either find it difficult to explain or they think it is so fundamental that it isn’t worth mentioning, ‘To be an effective interviewer, you should bear two things in mind: 1. You should be open-minded, avoid preconceived ideas about the requirements, and willing to listen to stakeholders. 2. You should prompt the interviewee to get discussions going by using a springboard question or a requirements proposal, or by working together on a prototype system, 3.1.2 Ethnography Ethnography is an observational technique that can be used to understand operational processes and help derive requirements for software to support these processes. An analyst immerses himself or herself in the working environment where the system will be used. ‘The day-to-day work is observed, and notes are made of the actual tasks in which participants are involved. The value of ethnographyis that it helps discover implicit system requirements that reflect the actual ways that people work, rather than the formal processes defined by the organization People often find it very difficult to articulate details of their work because it is second nature to them, They understand their own work but may not understand its relationship to other work in the organization, Ethnography is particularly effective for discovering two types of requirements: 1, Requirements derived from the way in which people actually work, rather than the way in which business process definitions say they ought to work. 2, Requirements derived from cooperation and awareness of other people's activities. Ethnography is helpful to understand existing systems, but this understanding does not always help with innovation. However, because of its focus on the end user, this approach is not effective for discovering broader organizational or domain requirements or for suggestion innovations. 4 Stories and scenarios People find it easier to relate to real-life examples than abstract descriptions. They are not good at telling you the system requirements. However, they may be able to describe how they handle particular situations or imagine things that they might do in a new way of working. Stories and scenarios are ways of capturing this kind of information Stories and scenarios are essentially the same thing. They are a description of how the system can be used for some particular task. They describe what people do, what information they use and produce, and what systems they may use in this process. Stories are written as present a high-level description of system use; scenarios are usually structured with specific information collected such as inputs and outputs. rrative text and A scenario starts with an outline of the interaction. During the elicitation process, details are added to create a complete description of that interaction. At its most general, a scenario may include: 1. A description of what the system and users expect when the scenario starts, 2. A description of the normal flow of events in the scenario, 3. A description of what can go wrong and how resulting problems can be handled. 4. Information about other activities that might be going on at the same time. 5. A description of the system state when the scenario ends. Uploading photos to KidsTakePics Initial assumption: A user or a group of users have one or more digital photographs to be uploaded to the picture-sharing site. These photos are saved on either a tablet or a laptop computer. They have successfully logged on to KidsTakePics. Normal: The user chooses to upload photos and is prompted to select the photos to be uploaded on the computer and to select the project name under which the photos will be stored. Users should also be given the option of inputting keywords that should be associated with each uploaded photo. Uploaded photos are named by creating a conjunetion of the user name with the filename of the photo on the local computer. On completion of the upload, the system automatically sends an email to the project moderator, asking them to check new content, and generates an on-screen message to the user that this checking has been done. What can go wrong: No moderator is associated with the selected project. An email is automatically generated to the school administrator asking them to nominate a project moderator. Users should be informed of a possible delay in making their photos visible.Photos with the same name have already been uploaded by the same user. The user should be asked if he or she wishes to re-upload the photos with the same name, rename the photos, or cancel the upload. If users choose to re-upload the photos, the originals are overwritten. If they choose to rename the photos, a new name is automatically generated by adding a number to the existing filename, Other acti are uploaded. ies: The moderator may be logged on to the system and may approve photos as they System state on completion: User is logged on. The selected photos have been uploaded and assigned a status “awaiting moderation.” Photos are visible to the moderator and to the user who uploaded them. 5 Requirements validation Requirements validation is the process of checking that requirements define the system that the customer really wants. Requirements validation is critically important because errors in a requirements document can lead to extensive rework costs when these problems are discovered during development or after the system is in service. “The cost of fixing a requirements problem by making a system change is usually much greater than repairing design or coding errors. A change to the requirements usually means that the system design and implementation must also be changed. Furthermore, the system must then be retested. Specify the requirements and read them to check that they meet their needs. Customers specity changes to the requirements. ‘System customers Use the requirements ts document to plan a bid for Manage the system and to plan the system development process. System Use the requirements to understand what system is to be developed. engineers nue During the requirements validation process, different types of checks should be carried out on the requirements in the requirements document. These checks include: 1. Falidity checks These check that the requirements reflect the real needs of system users. Because of changing circumstances, the user requirements may have changed since they were originally elicited. 2. Consistency checks Requirements in the document should not conflict. That is, there should not be contradictory constraints or different descriptions of the same system function. 3. Completeness checks The requirements document should include requireme functions and the constraints intended by the system user: 4. Realism checks By using knowledge of existing technologies, the requirements should be checked to ensure that they can be implemented within the proposed budget for the system. These checks should also take account of the budget and schedule for the system development. s that define all5. Verifiability To reduce the potential for dispute between customer and contractor, system requirements should always be written so that they are verifiable. This means that you should be able to write a set of tests that can demonstrate that the delivered system meets each specified requirement. A number of requirements validation techniques can be used individually or in conjunetion with one another: 1. Requirements reviews The requirements are analysed systematically by a team of reviewers who cheek for errors and inconsistencies. 2. Prototyping This involves developing an executable model of a system and using this with end- users and customers to see if it meets their needs and expectations. 3. Test-case generation Requirements should be testable. 6 Requirements change ‘The requirements for large software systems are always changing. One reason for the frequent changes is that these systems are often developed to address problems that cannot be completely defined. Because the problem cannot be fully defined, the software requirements are bound to be incomplete, During the software development process, the stakcholders’ understanding of the problem is constantly changing (Figure 4.18). The system requirements must then evolve to reflect, this changed problem understanding. Initial understanding ‘of problem Changed understanding of problem Initial requirements ao Time Once a system has been installed and is regularly used, new requirements inevitably emerge. This is partly a consequence of errors and omissions in the original requirements that have to be corrected. However, most changes to system requirements arise because of changes to the business environment of the system: 1. The business and technical environment of the system always changes after installation. New hardware may be introduced and existing hardware updated. 2, System customers impose requirements because of organizational and budgetary constraints 3. Large systems usually have a diverse stakeholder community, with stakeholders having different requirements, As requirements are evolving, you need to keep track of individual requirements and maintain links between dependent requirements so that you can assess the impact of requirements change: 6.1 Requirements management planning Requirements management planning is concerned with establishing how a set of evolving requirements will be managed. During the planning stage, you have to decide on a number of issues 1, Requirements identification Each requirement must be uniquely identified so that it can be eros referenced with other requirements and used in traceability assessments,2. A change management process This is the set of activities that assess the impact and cost of changes. 3. Traceability policies These policies define the relationships between each requirement and between the requirements and the system design that should be recorded. The traceability policy should also define how these records should be maintained. 4. Tool support Tools that may be used range from specialist requirements management systems to shared spreadsheets and simple database systems, Requirements management needs automated support, and the software tools for this should be chosen during the planning phase. You need tool support for: 1. Requirements storage The requirements should be maintained in a secure, managed data store that is accessible to everyone involved in the requirements engineering process. 2 Change management The process of change management (Figure 4.19) is simplified if active tool support is available. Tools can keep track of suggested changes and responses to these suggestions. 3. Traceability management As discussed above, tool support for traceability allows related requirements to be discovered. Some tools are available which use natural language processing techniques to help discover possible relationships between requirements. 6.2 Requirements change management Requirements change management should be applied to all proposed changes to a system's requirements after the requirements document has been approved. Change management is essential because you need to decide if the benefits of implementing new requirements are justified by the c of implementation. ‘There are three principal stages to a change management process: 1, Problem analysis and change specification The process starts with an identified requirements problem or, sometimes, with a specific change proposal. During this stage, the problem or the change proposal is analyzed to check that it is valid 2. Change analysis and costing ‘The effect of the proposed change is assessed using traceability information and general knowledge of the system requirements. The cost of making the change is estimated in terms of modifications to the requirements document and, if appropriate, to the system design and implementation. Once this analysis is completed, a decision is made as to whether or not to proceed with the requirements change. 3. Change implementation The requirements document, the system design and implementation, are modified. You should organize the requirements document so that you can make changes to it without extensive rewriting or reorganization. Identified Revised Problem | problem analysis and ‘Change analysis Change || fequirements change specification and costing implementation 7 Traceability matrix Traceability is a software engineering term that refers to documented links between software engineering work products (eg., requirements and test cases). A traceability matrix allows a requirements engineer to represent the relationship between requirements and other software engineering work products. Rows of the traceability matrix are labelled using requirement names and columns can be labelled with the name of a software engineering work product (e.g., a design clement or a test case). A matrix cell is marked to indicate the presence of a link between the two. The traceability matrices can support a variety of engineering development activities, They can provide continuity for developers as a project moves from one project phase to another, regardlessof the process model being used. Traceability matrices often can be used to ensure the engineering work products have taken all requirements into account. As the number of requirements and the number of work products grows, it becomes increasingly difficult to keep the traceability matrix up to date, Nonetheless, it is important to create some means for tracking the impact and evolution of the product requirements. 8 DEVELOPING USE CASES A use case tells a stylized story about how an end user (playing one of a number of possible roles) interacts with the system under a specific set of circumstances. The story may be narrative text, an outline of tasks or interactions, a template-based description, or a diagrammatic representation. A use case depicts the software or system from the end user's point of view The first step in writing a use case is to define the set of “actors” that will be involved in the story. Actors are the different people (or devices) that use the system or product. Actors represent the roles that people (or devices) play as the system operates. An actor and an end user are not necessarily the same thing. Not all actors are identified during the first iteration. Primary actors interact to achieve required system function and derive the intended benefit from the system. They work directly and frequently with the software, Secondary actors support the system so that primary actors can do their work. Once actors have been identified, use cases can be developed. A number of questions that should be answered by a use case: + Who is the primary actor, the secondary actor(s)? + What are the actor's goals? + What preconditions should exist before the story begins? ‘+ What main tasks or functions are performed by the actor? + What system information will the actor acquire, produce, or change? Recalling basic SafeHome requirements, we define four actors: homeowner (a user), setup manager (likely the same person as homeowner, but playing a different role), sensors (devices attached to the system), and the monitoring and response subsystem (the central station that monitors the SafeHome home security function), For the purposes of this example, we consider only the homeowner actor. The homeowner actor interacts with the home security function in a number of different ways using either the alarm control panel or a PC. The homeowner (1) enters a password to allow all other interactions, (2) inquires about the status of a security zone, (3) inquires about the status of a sensor, (#) presses the panic button in an emergeney, and (5) activates/deactivates the security system. Considering the situation in which the homeowner uses the control panel, the basic use case for system activation follows: “The homeowner observes the SafeHome control panel to determine if the system is ready for input. If the system is not ready, a not ready message is displayed on the LCD display, and the homeowner must physically close windows or doors so that the not ready message disappears. 2. The homeowner uses the keypad to key in a four-digit password. The password is compared with the valid password stored in the system. If the password is incorrect, the control panel will beep once and reset itself for additional input. If the password is correct, the control panel awaits further action. 8. The homeowner selects and keys in stay or away to activate the system. Stay activates only perimeter sensors (inside motion detecting sensors are deactivated). Away activates all sensors,The basic use case presents a high-level story that describes the interaction between the tl a qj actor and the system, In many instances, uses 0 cases are further elaborated to provide smax est bypass considerably more detail about the interaction, isnt codec 9 Software Requirements Specification Template A software requirements specification (SRS) is a work product that is created when a detailed description of all aspects of the software to be built must be specified before the project is to commence. It is important to note that a formal SRS is not always written, In fact, there are many instances in which effort expended on an SRS might be better spent in other software engineering activities. However, when software is to be developed by a third party, when a lack of specification would create severe business issues, or when a system is extremely complex or business critical, an SRS may be justified. »