Requirements Elicitation and Elaboration CSC 513 Dr. M. M. Pickard

How do we accomplish a software project? Just do it! Keep the effort organized: What comes first? Determine what is needed/wanted.

Example: Selection of Software Process Activities for a specific project Implemen- tation The Hacker knows only one activitity Possible activities for a more disciplined project Requirements Elicitation Analysis System Design Object Design Implemen- tation Testing Each activity produces one or more models

Model? What’s a model? An abstraction of a system aimed at simplifying the reasoning about the system by omitting irrelevant details. Requirements elicitation may produce a use case model. With scenarios.

Requirements Engineering Requirements Elicitation Requirements Analysis Referred to as “elaboration” by Pressman.

Requirements Engineering Requirements Analysis (Wikipedia) In systems engineering and software engineering, requirements analysis encompasses all of the tasks that go into the investigation, scoping and definition of a new or altered system. Requirements analysis is an important part of the system design process, whereby requirements engineers and business analysts, along with systems engineers or software developers, identify the needs or requirements of a client. Once the client's requirements have been identified, the system designers are then in a position to design a solution. Requirements analysis is also known by other names, such as: requirements engineering requirements gathering requirements capture operational concept documenting systems analysis requirements specification

In This Presentation: Requirements Engineering consists of two activities: Requirements Elicitation “Elicitation: To draw forth or bring out.” Merriam-Webster OnLine. Requirements Analysis Determine the relationships among identified requirements, how to satisfy them, and so forth. These are often overlapping, indistinct activities.

Requirements Elicitation Focus on user view of the system Identify Actors. Scenarios. Use cases. Relationships among use cases.

Actors Roles rather than persons. External entities that interact with the system of concern. Can be an external hardware or software system. Look for initiators of use cases.

Scenarios Can describe an interaction of the actor with the system. As currently done; As could be done; Used to help users and developers come to a common understanding of what the system should do. Start abstract; refine and complete during elaboration.

Use Cases, Scenarios A use case diagram graphically depicts one way in which an actor interacts with the system. A use case (eventually) includes all possible scenarios for a particular interaction. A scenario is a verbal description of one particular interaction of the user with the system.

Requirements Elicitation Functional requirements Interactions between the system and its actors; functional behavior of the system. Nonfunctional requirements Requirements that don’t work? No, requirements that have to do with how the interactions are facilitated. Examples: reliability, performance, usability, etc. “The system must respond within 1 second to user input.” See FURPS model discussed in text.

Nonfunctional Requirements Concern aspects of the system not related to functional behavior. Quality Requirements Relating to usability, reliability, performance, supportability. Constraints Other

Desirable Qualities of Requirements Realistic Verifiable Traceable Complete Consistent Unambiguous Correct

Desirable Qualities of Requirements Realistic – Possible and practical. Verifiable – Tests can show it’s there. Traceable – An unbroken line front to back Complete – All possible scenarios are represented. Consistent – No conflicts. Unambiguous – Multiple interpretations are not possible. Correct – Represents the client’s needs and the developer’s understanding of them.

Three Kinds of Projects- Different Effects on Reqts Elicititation Greenfield engineering Brand-new; no prior system. Reqts. elicited from users and client. Reengineering Start w/existing system. Reqts. extracted from it; users may add. Interface engineering Only the interface changes.

Requirements Document This is a deliverable of the requirements elicitation activity. May have aliases, e.g., Preliminary Requirements Document (PRD), Requirements Specification, etc., but the latter implies that some analysis has been done. Possible components List of requirements High level use case diagrams

Other Possible Requirements Engineering Work Products Feasibility analysis Technical Economic Identification of stakeholders Stakeholder – “Anyone who is affected in a direct or indirect way by the product which is being developed.” Prototypes

Elaboration (a.k.a. Requirements Analysis) Refine and complete use case diagrams. Create analysis model that includes identification of candidate classes. Other possible components: Refined use case diagrams showing product use under different conditions. Activity diagrams. Glossary.

Negotiation Resolve conflicting requirements. Prioritize requirements. Iteratively review requirements with clients. Eliminate. Combine. Modify. See Negotiation presentation.

Validation Formal technical review. Include users. Prototyping.

What did we cover? Definitions Identification of reqts using use cases Functional versus nonfunctional requirements Desirable qualities of requirements Types of projects as related to requirements Work products of requirements engineering Negotiation Validation