1. Chapter 4, Requirements Elicitation

2. Software Lifecycle Activities
Requirements
Elicitation
Requirements
Analysis
System
Design
Object
Design
Implemen-
tation
Testing
Implemented By
Expressed in Terms Of
Structured By
Realized By
Verified By
class... ?
class.... ?
Application
Domain
Objects
Use Case
Model
Implementation Domain
Objects
SubSystems
Source
Code
Test
Cases

3. Requirements Elicitation Activities
Identify actors
Identify scenarios
Identify use cases
Identify relationships among use cases
Refine use cases
Identify nonfunctional requirements
Identify participating objects

4. Defining the System Boundary: What do you see?
Another interesting issue with finding objects is to define which objects are inside the application domain and which ones are outside of it. Sometimes it helps you to get a clearer understanding of the overall system. Look at the figure in this slide. What does it show? A bunch of black and white dots? Given that I will tell you that it contains a system (that is an object model can be found) how would you start with looking for objects? Turn the slide around. Turn it upside down. Look at the “problem domain” from all angles. And suddenly you might experience what I would call the “gestalt experience”. You will see the application domain. Now there is no recipe for finding it. You might find a very low level object, such as an ear or you might find a high level object such as the shape of a dog. In fact, if you look carefully you will find a dalmatian dog. Once you understand that you are looking at a dog, a lot of the black and white pixels in the total figure are not part of your system and you can easily find the boundary of the system by trying to trace the outline of the Dalmatian.
However, don’t be lured into thinking that this is the system you have been looking for. Always be alert that the real system might be something totally different. For example, if you turn the dog upside down, you might be able to see an eagle taking off from a river, with a poor dead victim in its claws!

5. 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.
The identification of objects and the definition of the system boundary are heavily intertwined with each other.

6. Products of Requirements Process
Elicitation
analysis model
:Model
system
specification
Analysis

7. System Specification vs Requirements Analysis Model
Both focus on the requirements from the user’s view of the system.
System specification uses natural language (derived from problem statement)
Requirements analysis model uses formal or semi-formal notation (e.g., UML)

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

9. Types of Requirements
Functional requirements: Describe the interactions between the system and its environment independent from implementation
The watch system must display the time based on its location
Nonfunctional requirements: User visible aspects of the system not directly related to functional behavior.
The response time must be less than 1 second
The accuracy must be within a second
The watch must be available 24 hours a day except from 2:00am-2:01am and 3:00am-3:01am
Constraints (“Pseudo requirements”): Imposed by the client or the environment in which the system will operate
The implementation language must be COBOL.
Must interface to the dispatcher system written in 1956.

10. What is usually not in the Requirements?
System structure, implementation technology
Development methodology
Development environment
Implementation language
Reusability
It is desirable that none of these above are constrained by the client. Fight for it!

11. Requirements Validation
Critical step in the development process,
Usually after requirements engineering or requirements analysis. Also 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 functional or nonfunctional requirements that contradict each other
Clarity:
There are no ambiguities in teh requirements.

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

13. Requirements evolution
Requirements change rapidely during requirements elicitation. Tool for managing requirements:
RequisitPro from Rational
Stores requirements in a repository
Multi-user access
Automatically creates a requirements document from the repository
Provides traceability and change management throughout the project lifecycle

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

15. Scenarios
“A narrative description of what people do and experience as they try to make use of computer systems and applications” [M. Carrol, Scenario-based Design, Wiley, 1995]
A concrete, focused, informal description of a single feature of the system used by a single actor.
Scenarios can have many different uses during the software lifecycle

16. Types of Scenarios As-is scenario Visionary scenario
Used in describing a current situation. Usually used during re-engineering. The user describes the system.
Visionary scenario
Used to describe a future system. Usually described in greenfield engineering or reengineering.
Can often not be done by the user or developer alone
Evaluation scenario
User tasks against which the system is to be evaluated
Training scenario
Step by step instructions designed to guide a novice user through a system

17. How do we find scenarios?
Don’t expect the client to be verbal if the system does not exist (greenfield engineering)
Don’t wait for information even if the system exists
Engage in a dialectic approach (evolutionary, incremental)
You help the client to formulate the requirements
The client helps you to understand the requirements
The requirements evolve while the scenarios are being developed

18. Heuristics for finding Scenarios
Ask yourself or the client the following questions:
What are the primary tasks that the system needs to perform?
What data will the actor create, store, change, remove or add in the system?
What external changes does the system need to know about?
What changes or events will the actor of the system need to be informed about?
Insist on task observation if the system already exists (interface engineering or reengineering)
Ask to speak to the end user, not just to the software contractor
Expect resistance and try to overcome it

19. Summary Requirements Elicitation: Scenarios:
Greenfield Engineering, Reengineering, Interface Engineering
Scenarios:
Great way to establish communication with client
As-Is Scenarios, Visionary scenarios, Evaluation scenarios Training scenarios
Use cases: Abstraction of scenarios
Pure functional decomposition is bad:
Leads to unmaintainable code
Pure object identification is bad:
May lead to wrong objects, wrong attributes, wrong methods
The key to successful analysis:
Start with use cases and then find the participating objects
If somebody asks “What is this?”, do not answer right away. Return the question or observe: “What is it used for?”