Software Requirements Engineering: Activities, Types, and Elicitation, Study notes of Software Engineering

Download Software Requirements Engineering: Activities, Types, and Elicitation and more Study notes Software Engineering in PDF only on Docsity! Page 1 Software Lifecycle Activities Application Domain Objects SubSystems class... class... class... Implementat ion Domain Objects Source Code Test Cases ? Expressed in Terms Of Structured By Implemented By Realized By Verified By System Design Object Design Implemen- tation Testing class....? Requirements Elicitation Use Case Model Requirements Analysis Products of requirements elicitation and analysis Analysis problem statement functional model nonfunctional requirements analysis object model Requirements elicitation dynamic model Analysis Model Requirements Specification iterative uses natural language (derived from problem statement) and serves as a contract between client and developer uses formal or semi- formal notation (e.g., UML) Requirements Elicitation Activities ♦ Identify actors ♦ Identify scenarios ♦ Identify use cases ♦ Identify relationships among use cases ♦ Refine use cases ♦ Identify nonfunctional requirements ♦ Identify participating objects FieldOfficer DispatcherFRIEND System Identification ♦ Development of a system is not just done by taking a snapshot of a scene (domain) ♦ Definition of the system boundary What is inside, what is outside? ♦ How can we identify the purpose of a system? ♦ Requirements Process: Requirements Elicitation: Definition of the system in terms understood by the customer Analysis: Technical specification of the system in terms understood by the developer. Requirements Elicitation ♦ Challenging activity ♦ Requires collaboration of people with different backgrounds User with application domain knowledge Developer with implementation domain knowledge ♦ Bridging the gap between user and developer: Scenarios: Example of the use of the system in terms of a series of interactions with between the user and the system Use cases: Abstraction that describes a class of scenarios Types of Requirements ♦ Functional requirements: Describe the interactions between the system and its environment independent from implementation (e.g., the watch system must display the time based on its location) Focus on the purpose of the system rather than how the purpose is achieved or how efficiently the purpose is achieved Page 2 Types of Requirements ♦ Nonfunctional requirements: User observable aspects of the system not directly related to purpose but often specified at the same time as functional requirements. Look and feel of the user interface Documentation format requirements Hardware Performance The response time must be less than 1 second The accuracy must be within a second Error handling Quality (reliability/availability) The watch must be available 24 hours a day except from 2:00am- 2:01am and 3:00am-3:01am Security Resources Memory usage Cpu speed Types of Requirements ♦ Constraints (“Pseudo requirements”): Imposed by the client or the environment in which the system will operate. Restricts the implementation of the system. The implementation language must be Java. Must interface to the dispatcher system written in 1956. Must use Intel CPU What is usually not in the Requirements? ♦ System structure, implementation technology ♦ Development methodology ♦ Development environment ♦ Implementation language ♦ Reusability It is desirable that none of the above are constrained by the client. Requirements Validation ♦ Critical step in the development process, Usually after requirements elicitation or analysis. Also done at delivery. ♦ Requirements validation criteria: Correctness: The requirements represent the client’s view. Completeness: All possible scenarios through the system are described, including exceptional behavior by the user or the system Consistency: There are no functional or nonfunctional requirements that contradict each other. Clarity: There are no ambiguities in the requirements. Requirements Validation Criteria (continued) ♦ Realism: Requirements can be implemented and delivered. ♦ Traceability: Each system function can be traced to a corresponding set of functional requirements. Types of Requirements Elicitation ♦ Greenfield Engineering Development starts from scratch, no prior system exists, the requirements are extracted from the end users and the client Triggered by user needs ♦ Re-engineering Re-design and/or re-implementation of an existing system using newer technology Triggered by technology enabler ♦ Interface Engineering Provide the services of an existing system in a new environment Triggered by technology enabler or new market needs