1. Requirements Acquisition
ICS 121: Software Methods and Tools
Topic 3: Requirements Acquisition
Requirements Acquisition
Requirements Overview
Problem Analysis
Mockups through Prototyping
Spring 2000

2. Requirements Analysis and Specification
ICS 121: Software Methods and Tools
Topic 3: Requirements Acquisition
Requirements Analysis and Specification
Problem Definition
informal statement of need for system
Requirements Definition
natural language statement of what system is to provide
Requirements Specification
notational and/or formal description of a software system
Topic 3
Requirements Acquisition
Spring 2000

3. Why write requirements?
ICS 121: Software Methods and Tools
Topic 3: Requirements Acquisition
Why write requirements?
Develop a contract between customer and developer
Enables both sides to be clear about what is to be done
Understand and specify requirements based on customer’s needs
Not on what the developer thinks the customer needs
Provide basis for definitive testing and verification
System is acceptable if its passes the “acceptance” test
Topic 3
Requirements Acquisition
Spring 2000

4. Requirements in the Software Lifecycle
What ?
Topic 3
Requirements Acquisition

5. Goals for a requirements specification
ICS 121: Software Methods and Tools
Topic 3: Requirements Acquisition
Goals for a requirements specification
Identify the functional capabilities of the system
Identify desired responses to undesired events
Identify non-functional and environmental constraints to be satisfied
“My users will submit input in the form of Microsoft Word documents”
“It has to run on a ‘Pentium III under Windows 2000!”
Avoid specifying “how” focus simply on “what”
Serve as a guide to the development team
Topic 3
Requirements Acquisition
Spring 2000

6. Desirable Characteristics of a Requirements Specification
ICS 121: Software Methods and Tools
Topic 3: Requirements Acquisition
Desirable Characteristics of a Requirements Specification
Abstract
one model, many realizations
Complete
to the extent required
Consistent
no contradictions
Unambiguous
concrete acceptance test
Precise
uniquely interpretable
Testable
Concise
no extraneous details
Feasible
realistic constraints
Even
consistent level of detail
Modifiable
living document
Reference Tool
readable by all stakeholders
No implementation bias
Topic 3
Requirements Acquisition
Spring 2000

7. ICS 121: Software Methods and Tools
Topic 3: Requirements Acquisition
Common Problems
Incompleteness
customer may be unavailable or inaccessible
customer asks for too little
customer doesn’t think of everything
the world changes
Note: sometimes incompleteness is okay (as long as its noted!)
Inconsistency
customer may be a group that disagrees
different people may negotiate different parts
Ambiguity
customer may be a group where no one sees the whole picture
difficult to spot ambiguity in large, complex applications
Imprecision
customer may be a group with a different vocabulary
precision easiest in mature application areas (e.g. accounting)
precision difficult in new disciplines
Infeasibility
customer asks for too much
no conceivable algorithm
unrealistic requests
Unevenness
different sources of information
different people write different parts
different parts of specification are more difficult than others
Topic 3
Requirements Acquisition
Spring 2000

8. Requirements Acquisition
Caution
Shortchanging requirements phase
Emphasizing design
Substituting test plans for requirements
these are DEADLY
to later development
Topic 3
Requirements Acquisition

9. Requirements Analysis Process
Domain
understanding
Requirements
collection
validation
Prioritization
Conflict
resolution
Classification
definition and
specification
Process
entry
Topic 3
Requirements Acquisition

10. Products Refinement of customer needs
Documentation of all requirements and constraints
functional
nonfunctional
Lifecycle considerations
Acceptance Test Plan
Should not begin a project without a
GOOD CONTRACT
that completely describes customer expectations
Topic 3
Requirements Acquisition

11. Non-Functional Requirements
Efficiency
Usability
Reliability
Portability
Performance
Space
Delivery
Implementation
Standards
Legislative R.
Interoperability
Ethical R.
Privacy
Safety
requirements
Process
External
Non-functional
Topic 3
Requirements Acquisition

12. Method-based requirements analysis
Most widely used approach to requirements analysis
Depends on the application of some structured methods to understand the system
Results are expressed in a set of system models
Methods have different emphases: some are focused exclusively on requirements elicitation/analysis, others are very close to design
Structured methods usually include:
Process model (dataflow analysis, control scenario identification)
System modeling notations (diagrammatic, form-based, linguistic)
Rules applied to the system model
Design guidelines
Report templates
Topic 3
Requirements Acquisition

13. ICS 121: Software Methods and Tools
Topic 3: Requirements Acquisition
Basic Methods
Customer teaches; developer learns and organizes
Developer applies discipline to process and helps discover ambiguity, inconsistency, and incompleteness
Interviews, investigations, questionnaires
Informal description
Glossaries to aid communication
Mockups through prototyping and scenarios
Semi-formal description
Hierarchical decomposition
System modeling
Dataflow diagrams, E-R Diagrams, Finite state machines, Petri nets, etc.
Topic 3
Requirements Acquisition
Spring 2000

14. Informal Requirements Specification
ICS 121: Software Methods and Tools
Topic 3: Requirements Acquisition
Informal Requirements Specification
Structured Natural Language
Extended, more detailed form of the client’s requirements definition
Advantage
Uses expressiveness and understandability of natural language
Problems
Inherent ambiguity of natural language
Requirements are not partitioned effectively by the language itself (difficult to find related requirements)
Topic 3
Requirements Acquisition
Spring 2000

15. Typical contents of an informal (textual) Requirements Specification
ICS 121: Software Methods and Tools
Topic 3: Requirements Acquisition
Typical contents of an informal (textual) Requirements Specification
Description
restatement of problem definition
Functionality
“what” the system does
Data
“what” the system processes
Environment
“where” the system operates
Robustness
“what” is expected of the system in unusual circumstances
Security
“who” has access to “what”
Safety
can this system harm anyone
Performance
“what” constraints are placed on the system’s performance
Resources
“what” information/other systems is/are available to help the system accomplish its job
Topic 3
Requirements Acquisition
Spring 2000

16. ICS 121: Software Methods and Tools
Topic 3: Requirements Acquisition
Mockups
First step: build mockup for client/user experimentation
Rapid prototypes or scenarios as a means to understanding and requirements acquisition
serves as a communication device with the user
“I don’t know what I want, but I don’t want THAT!”
facilitates technical exploration
“Is this possible?”
refines the problem definition
“I want that …”
aids the development and assessment of specifications
“That looks good …”
also serves to build confidence that the developers are planning something that meets client’s needs
Next: follow another lifecycle model
Topic 3
Requirements Acquisition
Spring 2000

17. Rapid Prototyping and Scenarios
Address problems of requirements acquisition
completeness of user needs
adequacy of user services
usability of user interface
incomplete and/or inconsistent requirements specification
system feasibility
analysis of alternative design decisions
Help in understanding user needs
Is the proposed service/system adequate?
Is the user-interface usable?
Are the requirements complete?
Which alternative should we take?
e.g. present the user with multiple “throw-away” prototypes
Means of EARLY Requirements Analysis
Topic 3
Requirements Acquisition

18. Rapid Prototyping Lifecycle
ICS 121: Software Methods and Tools
Topic 3: Requirements Acquisition
Rapid Prototyping Lifecycle
Rapid Prototype
Verify
Retirement
Operations
Test
Implementation
Design
Req. Change
Scenarios can be used as mockups in the same way
Topic 3
Requirements Acquisition
Spring 2000

19. ICS 121: Software Methods and Tools
Topic 3: Requirements Acquisition
“Rapid” is key!
The prototype must be constructed quickly!
Thus, inconsequential problems are minor as long as main aspect of the prototype functions correctly
A prototype should be designed to be rapidly changed
This supports iteration in the process
If the user doesn’t like it, incorporate the feedback and try again!
To support these requirements, fourth-generation languages or interpreted languages are often used to generate prototypes
Topic 3
Requirements Acquisition
Spring 2000

20. Rapid Prototyping Tools
Executable specification languages
Animation of a formal system specification to provide a system prototype
Problems:
GUI cannot be prototyped
Executable system usually slow and inefficient
Executable specifications only test functional requirements
Very high level languages
Programming languages which include powerful data management facilities (simplifies program/prototype development)
Examples: Lisp, Prolog, Smalltalk, APL
Fourth-generation languages
Powerful languages, especially in the business system domain
Examples: Database Query Languages (including report generator, etc.)
Scenarios and Human-Computer Interaction
Topic 3
Requirements Acquisition

21. Exploratory Programming Lifecycle
Develop outline specification because full requirements are not known, build mockup system, expose to user review & enhance until performance is adequate B u i l d S o f t w a r e y s m O p n D v M c I P U
A similar but BAD approach!
Topic 3
Requirements Acquisition

22. Rapid Prototypes as specifications...
ICS 121: Software Methods and Tools
Topic 3: Requirements Acquisition
Rapid Prototypes as specifications...
Instead of discarding the prototype, use it to serve as the specification
Saves time having to write a specification document!
Generally considered a bad idea...
because
a rapid prototype can’t serve as a legal contract
a rapid prototype does not make for good documentation
It can’t serve as a reference tool for maintenance, for example.
Prototypes should be used to elicit requirements and then discarded, next comes design...
Topic 3
Requirements Acquisition
Spring 2000

23. Rapid Prototypes as the finished product!
ICS 121: Software Methods and Tools
Topic 3: Requirements Acquisition
Rapid Prototypes as the finished product!
Also considered a bad idea...
Same problems as previous...
Plus
Its too easy to slip into the build-and-fix lifecycle!
Topic 3
Requirements Acquisition
Spring 2000

24. ICS 121: Software Methods and Tools
Topic 3: Requirements Acquisition
Training the client...
Customer and/or users may confuse a prototype with the operational system
“Why do we have to wait so long for the system, didn’t you have it working three months ago?”
Customer may request more features than originally intended
“Hey that’s great! Can you add this...and this?”
Thus...client should be informed as to the purpose of the prototype and be aware of the position of requirements in the life-cycle...
Topic 3
Requirements Acquisition
Spring 2000