CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Chapter 7 Requirements Engineering Elements of software requirement gathering

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. What is Software Requirement? “A software requirement is a description of the principle features of a software product, its information flow, its behavior, its attributes. In sum, a software requirement provides a blueprint for the development of a software product. The degree of understandability, accuracy, and rigor of the description provided by a software requirement document tends to be directly proportional to the degree of quality of the derived product.” Source: Software Engineering: An Engineering Approach, by James Peters and Witold Predrycz, Wiley, 2000, Page 118.

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Requirements Engineering Goal: Better understanding of the problem at hand and business impact of the system. How is it done? Through a process that facilitates a set of defined tasks. Why do it? To establish a solid foundation for system design and construction. It is not the solution, but an approach to facilitate the development of a effective solution.

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. What is Software Requirements Analysis? - 1 Software requirements analysis is process of understanding customer requirements of the software system to be built, and building analysis model of the system (data, functions, behaviour/control flow, interfaces). The analysis model serves as - basis for creating specifications and software design - means for assessing the quality of the system to be built This process requires active participation of the customer, and it is crucial step in the development process. The analyst may play different roles - interrogator, advisor, problem solver, and negotiator.

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. What is Software Requirements Analysis? - 2 The outcome of the process: - Software Requirements Specifications (SRS). The SRS should be clear, complete, and consistent with customer needs. - Quality Assurance Plane - set of activities that the project team can follow to ensure software quality throughout the product life cycle (portability, reliability, efficiency, V&V criteria, cost, acceptance criteria, etc…)

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. System vs. Software Requirements System requirements analysis, in part, focus on how the software element interacts with other elements of the system (constraints and limitations). Software requirements analysis focus on the data, functional, and behavioural modeling of the software itself (OOA focuses on classes, relations, and object behaviour modeling). For software requirements analysis, try to fully answer the following: - What are the inputs and outputs? - What functions should be defined? - What behaviors (control activities) should be exhibited? - What interfaces are needed?

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Why Do Requirements Analysis? - Identify the customer and work together to negotiate product- level requirements - Build an analysis model (focus on data, define functions, represent behaviour) - Prototype areas of uncertainty in the system - Develop a specification to guide the design and development - Conduct formal technical reviews to ensure software quality

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. The Analysis Process the problem requirements elicitation build a prototype create analysis models develop Specification Review

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Problem Analysis OperationsProductsEnvironmentFunctions - People (operators and users) - Devices - Other items affected by the system - business value - Inputs - Outputs - Items produced for the system - People functions - Device functions - Other functions needed to produce services and items - Methods used - operations used to produced items - When operations occur

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Real Problems… - the customer has only a vague idea of what is required. - the customer keeps changing requirements. - the software engineer (analyst) is willing to proceed with the vague idea on the assumption that we'll fill in the details as we go. - the software engineer (analyst) is affected by the changes, making errors in the specifications. -?-? -?-? -and so it goes...

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Requirements Engineering Work Tasks - 1 Inception: Starting the project… where to star? Ask a set of questions that establish - basic understanding of the problem - the people who want a solution - the nature of the solution that is desired, and - the effectiveness of initial communication and collaboration between the customer and the developer Elicitation: Elicit requirements from all stakeholders Elaboration: Modeling and refinement (chapter 8) - create analysis model that identifies data, function, and behavioral requirements. (in OOA, analysis classes, their services, their relationships). Negotiation: Agree on a deliverable system that is realistic for developers and customers.

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Requirement Engineering Work Tasks - 2 Specification: Can be any one (or more) of the following: –A written document –A set of models –A formal mathematical –A collection of user scenarios (use-cases) –A prototype Validation: A review mechanism that looks for –Errors in content or interpretation –Areas where clarification may be required –Missing information –Inconsistencies (a major problem with large systems) –Conflicting or unrealistic (unachievable) requirements –Conformity issues (with standards set for the product, process, project)

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Requirement Engineering Work Tasks - 3 Requirements management: A process to identify, control, and track changes to requirements (similar to SCM) Traceability tables facilitate requirements management –feature (of system) traceability table (see figure 7.1, page 148) –source (of requirements) traceability table –dependency (among requirements) traceability table –subsystem traceability table (categorization of requirements) –interface traceability table

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Inception – Start the project Identify stakeholders –“who else do you think I should talk to?” Recognize multiple points of view Work toward collaboration (productive meetings) The first questions to ask: –Who is behind the request for this work? –Who will use the solution? –What will be the economic benefit of a successful solution? –Is there another source for the solution that you need? –…–… (see page 152)

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Elicitation - 1 Initial interview: - break the ice and establish communication channels - scripted (context-free) questions may be used understand customer goals and scope the problem identify stakeholders interested in the system Sample questions: - What do you expect of the new system? - How will the system help your organization? - Who will be using the system? - Will the system interact with other systems? - etc…

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Elicitation - 2 There is not one way for gathering requirements from the client… The meeting format determines its effectiveness and outcomes. It is important to listen, but that is not enough! In addition to meeting notes, recording the meetings may be required. One approach is called Facilitated Application Specification Techniques (FAST). It is a team-oriented approach to promote constructive and effective communications.

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. FAST Approach Guidelines: participants must attend entire meeting all participants are equal preparation is as important as meeting all pre-meeting documents are to be viewed as proposed off-site meeting location is preferred. Why? set an agenda and maintain it focus on requirements and don’t get mired in technical details Benefits: many points of view, instantaneous discussion and refinement, concrete step toward developing specs.

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Collaborative Approach Guidelines: (in the textbook) Meetings are attended by both software engineers and customers Preparation and participation rules are established Set an agenda Assign a facilitator (customer, developer, outsider) to manage the meeting Utilize a "definition mechanism" (work sheets, flip charts, wall stickers, E-bulletin board, chat room, or virtual forum) The goal is to identify the problem, propose a solution, negotiate different approaches, and specify a preliminary set of requirements

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Quality Function Deployment (QFD) Another approach for requirements gathering. Its purpose is to maximize customer satisfaction while developing software requirements that are valuable to the customer. It identifies three types of requirements: - Normal requirements: what the customer explicitly states and wants in the system. - Expected requirements: what the customer wants but did not explicitly state assuming we know such requirements. - Exciting requirements: additional features we can offer. Check QFD Institute at

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Elicitation Work Products a statement of need and feasibility (or statement of work). a bounded statement of scope for the system or product. a list of customers, users, and other stakeholders who participated in requirements elicitation. a description of the system’s technical environment. a list of requirements (preferably organized by function) and the domain constraints that apply to each. a set of usage scenarios that provide insight into the use of the system or product under different operating conditions. any prototypes developed to better define requirements.

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Use-Cases - 1 Another approach to requirement gathering is Use-cases. Use case are scenarios of system usage by different actors (classes of users and devices). e.g., student, faculty, and registrar are actors for student registration system. - Uses-cases are used to: - obtain requirements from the customer - effectively express requirements to the customer Annotated diagrams are common way to present use-cases.

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Use-Cases - 2 Some of the questions a use-case should answer: - What are the main functions performed by the actor? - What information will the actor acquire, produce or change? - What information does the actor desire of the system? - others… Check the article “Structuring Use Cases with Goals” at: Structuring+use+cases+ with+goals See example page 161. Retrieve a file use-case 1. User clicks file menus 2. System displays options new and open 3. User clicks option open 4. System displays open file window 5. User enters/selects file name 6. User clicks open button 7. System retrieves and opens the file

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Analysis Principles - 1 Analysis methods may vary, but they share common principles: 1. Information Domain Analysis and Data modeling: - define data (and control) items/objects - describe data attributes - establish data relationships and data structures e.g., student transcript (data object) with different attributes. 2. Function modeling: (iterative process) - identify functions that transform data objects - indicate how data flow through the system - represent producers and consumers of data objects

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Analysis Principles Behaviour modeling: - indicate different states of the system - specify events that cause the system to change state 4. Partitioning the model: refine each sub-model to represent lower levels of abstraction - refine data objects - create a functional hierarchy - represent behavior at different levels of details 5. The essence: focus on the problem (requirements) not the implementation details (i.e., answer “what” questions).

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Validate Requirements - 1 Is each requirement consistent with the overall objective for the system/product? Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage? Is the requirement really necessary or does it represent an add- on feature that may not be essential to the objective of the system? Is each requirement bounded and unambiguous? Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement? Do any requirement conflict with other requirements?

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Validate Requirements - 2 Is each requirement achievable in the technical environment that will house the system or product? Is each requirement testable, once implemented? Does the requirements model properly reflect the information, function and behavior of the system to be built. Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system. Have requirements patterns been used to simplify the requirements model. Have all patterns been properly validated? Are all patterns consistent with customer requirements?

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Deployment Practices Deployment involves system delivery, end-user support, and feedback from end-users. Principles: –Manage customer expectations for each increment –A complete delivery package should be assembled and tested –A support group should be established before delivery –Instructional materials must be provided to end-users –Buggy software should be fixed first, delivered later –Encourage and collect customer feedback on the system

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Suggested Problems Consider working the following problems from the end of chapter 7, page 173, for practice purpose: 7.1, 7.2, 7.3, 7.4, 7.11, 7.13, 7.16, 7.17 No submission is required. Think about these problems and work them for yourself!

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Last Slide End of Chapter 7