Lecture 3: Software Requirements Elicitation and Analysis PDF

Chapter 3 Software Requirements Elicitation and Analysis Shari L. Pfleeger Joanne M. Atlee 4th Edition Prepared by Dr. Noorayisahbe Contents The Requirements Process Requirements Elicitation Types of Requirements Characteristic of Requirements Modeling Notations...

Chapter 3 Software Requirements Elicitation and Analysis Shari L. Pfleeger Joanne M. Atlee 4th Edition Prepared by Dr. Noorayisahbe Contents The Requirements Process Requirements Elicitation Types of Requirements Characteristic of Requirements Modeling Notations Requirements and Specification Languages Prototyping Requirements Requirements Documentation Validation and Verification Measuring Requirements Choosing a Specification Technique Information System Example Real Time Example Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.2 Chapter Objectives Eliciting requirements from the customers Modeling requirements Reviewing requirements to ensure their quality Documenting requirements for use by the design and test teams Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.3 The Requirements Process A requirement is an expression of desired behavior A requirement deals with – objects or entities – the state they can be in – functions that are performed to change states or object characteristics Requirements focus on the customer needs, not on the solution or implementation – designate what behavior, without saying how that behavior will be realized Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.4 The Requirements Process Sidebar Why Are Requirements Important? Top factors that caused project to fail – Incomplete requirements – Lack of user involvement – Unrealistic expectations – Lack of executive support – Changing requirements and specifications – Lack of planning – System no longer needed Some part of the requirements process is involved in almost all of these causes Requirements error can be expensive if not detected early Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.5 The Requirements Process Process for Capturing Requirements Performed by the req. analyst or system analyst The final outcome is a Software Requirements Specification (SRS) document Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.6 Requirements Elicitation Customers do not always undertand what their needs and problems are It is important to discuss the requirements with everyone who has a stake in the system Come up with agreement on what the requirements are – If we can not agree on what the requirements are, then the project is doomed to fail Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.7  Techniques for Effective Requirements Elicitation Interviews and Surveys Conducting interviews and surveys allows for direct feedback from users, helping to gather specific needs and pain points effectively. Workshops and Brainstorming Sessions Facilitated workshops promote collaborative discussions among stakeholders, fostering creativity and generating diverse ideas for requirements. Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.8  Techniques for Effective Requirements Elicitation (Cont.) Prototyping and User Feedback Creating prototypes enables stakeholders to visualize requirements, leading to more accurate feedback and adjustments before finalization. Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.9  Analyzing and Documenting Requirements Prioritizing Requirements Establishing a prioritization process helps in focusing on the most critical requirements, ensuring essential features are developed first. Creating Clear Documentation Well-documented requirements serve as a reference point for developers, helping to ensure that the final product aligns with stakeholder expectations. Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.10 Requirements Elicitation Stakeholders Clients: pay for the software to be developed Customers: buy the software after it is developed Users: use the system Domain experts: familiar with the problem that the software must automate Market Researchers: conduct surveys to determine future trends and potential customers Lawyers or auditors: familiar with government, safety, or legal requirements Software engineers or other technology experts Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.11 Requirements Elicitation Sidebar Using Viewpoints to Manage Inconsistency No need to resolve inconsitencies early in the requirements process (Easterbrook and Nuseibah, 1996) Stakeholders' views documented and maintained as separate Viewpoints through the software development process – The requirements analyst defines consistency rules that should apply between Viewpoints – The Viewpoints are analyzed to see if they conform to the consistency requirements Inconsistencies are highlighted but not adressed until there is sufficient information to make informed decision Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.12 Requirements Elicitation Means of Eliciting Requirements Interviewing stake holders Reviewing available documentations Observing the current system (if one exists) Apprenticing with users to learn about user's task in more details Interviewing user or stakeholders in groups Using domain specific strategies, such as Joint Application Design, or PIECES Brainstorming with current and potential users Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.13 4.2 Requirements Elicitation Means of Eliciting Requirements (continued) The Volere requirements process model suggests some additional sources for requirements Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.14 Characteristics of Requirements Correct Consistent Unambigious Complete Feasible Relevant Testable Traceable Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.15 Modeling Notations It is important to have standard notations for modeling, documenting, and communicating decisions Modeling helps us to understand requirements thoroughly – Holes in the models reveal unknown or ambiguous behavior – Multiple, conflicting outputs to the same input reveal inconsistencies in the requirements Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.16  Exploring Visual Techniques for Requirement Gathering Creating Use Case Diagrams Use case diagrams visually represent interactions between users and the system, clarifying requirements and user roles. Developing Prototypes for User Feedback Prototypes provide a tangible representation of the system, enabling users to interact and offer feedback on design and functionality. Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.17  Exploring Visual Techniques for Requirement Gathering Employing Storyboarding to Illustrate Scenarios Storyboarding helps visualize the user journey, making it easier to identify requirements and understand user interactions with the system. Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.18 Modeling Notations Entity-Relationship Diagrams A popular graphical notational paradigm for representing conceptual models Has three core constructs – An entity: depicted as a rectangle, represents a collection of real-world objects that have common properties and behaviors – A relationship: depicted as an edge between two entities, with diamond in the middle of the edge specifying the type of relationship – An attribute: an annotation on an entity that describes data or properties associated with the entity Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.19 Modeling Notations Functions and Relations Formal methods or approach: mathematically based specification and design techniques Formal methods model requirements or software behavior as a collection of mathematical functions or relations – Functions specify the state of the system's execution, and output – A relation is used whenever an input value maps more than one ouput value Functional method is consistent and complete Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.20 Requirements and Specification Languages Unified Modeling Language (UML) Combines multiple notation paradigms Eight graphical modeling notations, and the OCL constrain language, including – Use-case diagram (a high-level DFD) – Class diagram (an ER diagram) – Sequence diagram (an event trace) – Collaboration diagram (an event trace) – Statechart diagram (a state-machine model) – OCL properties (logic) Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.21 Requirements and Specification Languages Specification and Description Language (SDL) Standardized by the International Telecommunication Union Specifies the behavior of real-time, concurrent, distributed processes that communicate with each other via unbounded message queues Comprises – SDL system diagram (a DFD) – SDL block diagram (a DFD) – SDL process diagram (a state-machine model) – SDL data type (algebraic specification) Often accompanied by a set of Message Sequence Chart (MSC) Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.22 Requirements and Specification Languages Other Features of Requirement Notations Some techniques include notations – for the degree of uncertainty or risk with each requirement – for tracing requirements to other system documents such as design or code, or to other systems, such as when requirements are reused Most specification techniques have been automated to some degree Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.23 Prototyping Requirements Building a Prototype To elicit the details of proposed system To solicit feedback from potential users about – what aspects they would like to see improve – which features are not so useful – what functionality is missing Determine whether the customer's problem has a feasible solution Assist in exploring options for otimizing quality requirements Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.24 Prototyping Requirements Prototyping Example Prototype for building a tool to track how much a user exercises each day Graphical respresentation of first prototype, in which the user must type the day, month and year Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.25 Prototyping Requirements Prototyping Example (continued) Second prototype shows a more interesting and sophisticated interface involving a calendar – User uses a mouse to select the month and year – The system displays the chart for that month, and the user selects the appropriate date in the chart Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.26 Prototyping Requirements Prototyping Example (continued) Third prototype shows that instead of calendar, the user is presented with three slide bars – User uses the mouse to slide each bar left or right – The box at the bottom of the screen changes to show the selected day, month, and year Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.27 Prototyping Requirements Prototyping vs. Modeling Prototyping – Good for answering questions about the user interfaces Modeling – Quickly answer questions about constraints on the order in which events should occur, or about the synchronization of activities Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.28 Requirements Documentation Requirement Definition: Steps Documenting Process Outline the general purpose and scope of the system, including relevant benefits, objectives, and goals Describe the background and the rationale behind proposal for new system Describe the essential characteristics of an accepatable solution Describe the environment in which the system will operate Outline a description of the proposal, if the customer has a proposal for solving the problem List any assumptions we make about how the environment behaves Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.29 Requirements Documentation Requirements Specification: Steps Documenting Process Describe all inputs and outputs in detail, including – the sources of inputs – the destinations of ouputs, – the value ranges – data format of inputs and output data – data protocols – window formats and organizations – timing constraint Restate the required functionality in terms of the interfaces' inputs and outputs Devise fit criteria for each of the customer's quality requirements Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.30 Requirements Documentation Sidebar 4.6 Level of Specification Survey shows that one of the problems with requirement specifications was the uneven level of specification – Different writing sytles – Difference in experience – Different formats – Overspecifying requirements – Underspecifying requirements Recommendations to reduce unevenness – Write each clause so that it contains only one requirement – Avoid having one requirement refer to another requirement – Collect similar requirements together Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.31 Requirements Documentation Sidebar 4.7 Hidden Assumptions Two types of environmental behavior of interest – desired behavior to be realized by the proposed system – existing behavior that is unchanged by the proposed system often called assumptions or domain knowledge Most requirements writers consider assumptions to be simply the conditions under which the system is guaranteed to operate correctly Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.32 Validation and Verification In requirements validation, we check that our requirements definition accurately reflects the customer's needs In verification, we check that one document or artifact conforms to another Verification ensures that we build the system right, whereas validation ensures that we build the right system Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.33 Validation and Verification List of techniques to validate requirements Validation Walkthroughs Readings Interviews Reviews Checklists Models to check functions and relationships Scenarios Prototypes Simulation Formal inspections Verification Cross-referencing Simulation Consistency checks Completeness checks Check for unreachable states of Checking transitions Model checking Mathematical proofs Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.34 4.9 Validation and Verification Requirements Review Review the stated goals and objectives of the system Compare the requirements with the goals and objectives Review the environment in which the system is to operate Review the information flow and proposed functions Assess and document the risk, discuss and compare alternatives Testing the system: how the requirements will be revalidated as the requirements grow and change Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.35 Validation and Verification Number of Requirements Faults Jone and Thayes's studies show that – 35% of the faults to design activities for project of 30,000-35,000 delivered source instructions – 10% of the faults to requirements activities and 55% of the faults to design activities for projects of 40,000-80,000 delivered source instructions – 8% to 10% of the faults to requirements activities and 40% to 55% of the faults to design activities for project of 65,000-85,000 delivered source instructions Basili and Perricone report – 48% of the faults observed in a medium-scale software project were attribute to “incorrect or misinterpreted functional specification or requirements” Beizer attributes 8.12% of the faults in his samples to problems in functional requirements Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.36 Validation and Verification Verification Check that the requirements-specification document corresponds to the requirements- definition Make sure that if we implement a system that meets the specification, then the system will satisfy the customer's requirements Ensure that each requirement in the definition document is traceable to the specification Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.37 Measuring Requirements Measurements focus on three areas – product – process – resources Number of requirements can give us a sense of the size of the developed system Number of changes to requirements – Many changes indicate some instability or uncertainty in our understanding of the system Requirement-size and change measurements should be recorded by requirements type Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.38 What This Chapter Means for You It is essential that the requirements definition and specification documents describe the problem, leaving solution selection to designer There are variety of sources and means for eliciting requirements There are many different types of definition and specification techniques The specification techniques also differ in terms of their tool support, maturity, understandability, ease of use, and mathematical formality Requirements questions can be answered using models or prototypes Requirements must be validated to ensure that they accurately reflect the customer's expectations Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.39  Thank you Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 4.40