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

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

3. 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

4. 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.

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

6. 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

7. 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.

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

9. 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.

10. 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.

11. 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.

12. 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.

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

14. Desirable Qualities of Requirements
Realistic
Verifiable
Traceable
Complete
Consistent
Unambiguous
Correct

15. 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.

16. 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.

17. 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

18. 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

19. 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.

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

21. Validation
Formal technical review.
Include users.
Prototyping.

22. 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