Softeng - Software Requirements Feb 2004

Software Engineering
Wouter Brissinck
2005
Managing Software Requirements : Ch 1-The Requirements Problem
The Goal of Software

Development
• Software Quality implements Murphy’s law
– Must be perfect for ordinary software
– Must be ridiculously perfect when lives are at stake
• On time, within budget
• Meet real customer’s needs
– Off the shelf
– Project-based, tenders, …
– Internal
Software Engineering = ?
“The establishment and use of sound engineering
principles in order to obtain economically
software that is reliable and works efficiently on
real machines”
Fritz Bauer
“The application of a systematic, disciplined,
quantifiable approach to development, operation
and maintenance of software”
IEEE
Managing Software Requirements : Ch 3-Requirements and the Software Lifecycle
Software Development Process

– Every project needs a process
• Defines responsibilities of team members
• Defines which activities are performed
• Defines timing in relation to other activities
• Defines details and steps in the activities
• Defines required registrations of the activities, to
insure traceability
– Always document the process
• Helps new people on the team
• Required by quality standards (ISO 9001)
Software Development
Procedures
• Procedures :
– Define terms
– Define responsibilities
– Define methods
– Plan/Do/Measure/Act
– Create registrations
• Adapt the procedures to the project & team
The Waterfall Model

– Pre-historic : code & fix (2-phase model)
– 50-60ies : Waterfall model (requirements ->
design -> code -> etc …)
• Emphasize need for requirements
– 1970 (Royce) : Improved Waterfall Model
• Feedback loops (design affects requirements, …)
• Develop Prototype system during requirements and
design activities
The Waterfall Model

The Waterfall Model

– Problems
• Real projects are not sequential
• Creates barriers between phases
• Requirements are “frozen” to the lifetime of the project
– Independent of market situation or user’s needs
• Doesn’t take scope management into account
– No means to react on underestimation of the effort required
• Changes in “closed” process confuse people
• Requirements seldom known beforehand
• Result obtained very late in the process
– Errors can be very costly
The Spiral Model

– Boehm (1988)
• Successively build Product spec – prototype – core
version – functional version – enhanced version –
etc …
• Each version undergoes similar process
– Sequence of task regions (waterfall …)
– Each region defines task set (adapted to project)
• Allows for several phases of customer feedback,
combined with a rigorous sequential process
– Better understanding of the system after each iteration
• Reduce risk using prototypes
Spiral Model
The Spiral Model

– Problems
• Prototypes give users the feeling it’s “done”
• Prototype code is often transferred to
production code
– Creates instant legacy code
• Usually no time to produce several
prototypes …
The Iterative Approach

– Kruchten (1995)
• Decouple lifecycle phases from software
development activities
– Phases vs. Iterations
• Mitigate whatever risks are present in each stage of
development

– 4 Lifecycle Phases
• Inception :
– Understand the business case for the project
– Understand feasibility of implementation
– Perform problem analysis
– Create a vision for the solution
– Define preliminary estimates of schedule and budget
– Define project risk factors
• Elaboration
– Redefine requirements
– Define initial architecture
– Develop first prototype

– 4 Lifecycle Phases
• Construction
– Focus on implementation
– Coding
– Unit testing
• Transition
– Beta Testing
– Train users and maintainers
– Deploy

– Iterations
• Iteration = sequence of activities with an established
plan and evaluation criteria, resulting in a
deliverable (release)
• Mini-waterfalls, tuned to the phase
– Disciplines
• Logically related set of activities
• Defines how activities must be sequences to produce
a deliverable

Requirements in the Iterative

Approach
– Requirement activities are performed throughout the
lifecycle
• Refine requirements (increase level of detail) during each
iteration
• Add requirements late in the project
– Scope Management
• Early iterations provide input the planning of the next
– How difficult are things ?
– How fast is the team ?
– Should we reduce scope, or can we do more ?
• When requirements are well prioritized, each iteration will
provide a useful deliverable to the customer
Key Points
– The team’s development process defines who is doing
what, when and how
– In the waterfall model, software proceeded through a
sequence of steps, and requirements were fixed early
– In the spiral model, the first steps were taken to a more
risk driven and incremental approach to development
– The iterative approach, a hybrid of the waterfall and
spiral models, decouples the lifecycle phases from the
software activities that take place in each phase
– The iterative model is a more robust model and
provides for successive refinement of the requirements
over time
Software Requirements
Wouter Brissinck
2005
Bibliography
• Use Cases – Requirements in Context, D.Kulak,
Eamonn Guiney, Addison Wesley, 2000, ISBN 0-
201-65767-8
• Software Requirements – Styles and Techniques,
Soren Lauesen, Addison Wesley, 2002, ISBN 0-
201-74570-4
• Managing Software Requirements, Dean
Leffingwell, Don Widrig, Addison-Wesley, ISBN
0-321-12247
The Numbers
• In 1994 in the US :
– $250,000,000,000 on 175,000 projects
– Average cost :
• $2,322,000 for a large company
• $1,331,000 for a medium company
• $434,000 for a small company
– 31% of the projects failed
– 52.7% cost 189% of the budget
– $81,000,000,000 is spent on failed projects
– $59,000,000,000 is spent too much on successful
projects
The Root Causes of Failure

The Root Causes of Failure

– 1/3rd of the projects report as root causes :
• Requirements specs
• Managing requirements
– Coding is not the problem
The Frequency of Requirements

Errors
High Cost of Requirements

Errors
High Cost of Requirements

Errors
– Potential 200x higher cost in fixing error in
maintenance phase vs. requirements phase.
– Study :
• 74% of requirements-oriented issues find during requirements
analysis
• 7% leak into design
• 4% leak into maintenance
– To fix : respecify, redesign, recode, retest, redeploy,
corrective action, scrap, warranties, liabilities,
redocument, …
– Requirements issues : 25%-40% of the project budget
The Requirements Problem : Key

Points
• Goal : quality software, on time and budget,
which meet customer’s real needs
• Success depends on effective requirements
management
• Requirements errors are the most common,
and the most expensive to fix
Contents
• What is a requirement ?
• Elicitation
• The requirement document
• Techniques for documenting requirements :
– Prototypes
– Use Cases
– Task Descriptions
What is a Requirement ?
• Specific feature, function, or principle a
system must provide
• Scope of a software project
Three kinds :
• Data :
• Functional : e.g. “When the user types a keyword and performs
the ‘search the web’ command, a list of web-pages referring to the
keyword are displayed”
• Non-functional ( -ilities) : e.g. “The system should
react to all user input within one minute”
Tacit Requirements
• Tacit requirement = everybody agrees
about it, but it cannot be written down ;
implied requirement
– Most demands are tacit
– Requirements only contain what developers
cannot guess (+a bit more to make sure)
Don’t expect you can specify it all

Requirements Gathering
(elicitation): Challenges
AIM of a software project :
« Deliver quality software application, on
time, within costs, and to user’s
expectations »
Problem : business changes, requirements too
We need requirements management

Managing Software Requirements : Ch 2-Introduction to Requirements Management
What is Requirements
Management ?
– A systematic approach to eliciting, organizing, and
documenting the requirements of a system
– Organize = ?
• Store
• Prioritize
• Control access to
• Assign responsibilities (to the requirement’s documentation
itself)
• Requirement dependencies (what is affected if changed ?)
• Traceability (who develops when, which design doc, which
code, which test cases, …)
Purpose of requirements
• Validation : check that reqs==user needs
• Verification : check that product satisfies
requirements (e.g. acceptance test)
• Tracing ( demands ↔ reqs ↔ program )
• Requirements management
• Court cases (tacit reqs !!)
• Job of the analyst :
– Elicit
– Analyze for consistency
– Analyze for feasibility
– Analyze for Completeness
– Write it down
• Who is part of the req. gathering team ?
– Project managers
– Developers
– Expert users (customer !)
– Subcontractors
– + consultants, marketing, …
Communicating with users …
• Improve your relationship with users
• Improve visibility of the project
• Have respect for user’s time, job content,
skills, …
Write a requirements document
• Redundant ? Complete ?
• Detailed, but not too large ?
• Readable by the users and the IT people ?
Requirements : Challenges
• Reduce Risk
• Focus on Interactions (NOT Technology)
• Reduce Volume
• No Redundancy, No Conflicts
• Useful to User, Designer, Developer, Manager
• Traceable
• No Design
• Useful till the end of the project
Traceability
Everybody on the project should be able to
tell at each time during the lifetime of the
project what requirement he is working on
(analist, developer, tester, maintenance
developer, …)
The trouble with requirements
gathering
• They don’t know what an IT system could do for
them
• They don’t know what they want
• They have conflicting demands
• They don’t have time
• They change their minds
• They don’t understand IT
• Yes, but ...
• They want it all on paper before you start
Problems observed in practice
• Data and functional requirements
– Usually developers guess right
• Expectations not met
– Business goals not understood by developers
• Background and context
– Requirements’ purpose not understood by developers
• Quality requirements
– Get too little attention in reqs doc.
The basic rule of writing
requirements
Requirements and design are different things

Signs of bad requirements
• Requirements ≠ Design , What ≠ How,
Understanding ≠ Solving
• Vagueness
• Use of IT jargon (instead : User’s Jargon)
Signs of Bad Requirements
« The system should provide restricted remote access
(via dial-in) to allow downloading of jpg images »
« When the user clicks the « select company »

button, the system will show the list of company
IDs by performing a query through the ODBC
connection, or by accessing the cache if this query
was performed recently »
« The system should provide restricted remote access
(via dial-in) to allow downloading of jpg images »
« When the user clicks the « select company »

button, the system will show the list of company
IDs by performing a query through the ODBC
connection, or by accessing the cache if this query
was performed recently »
« The telephone system must provide a voice
response menu, going from a general menu to a
secondary menu »
« All useful parameters should be present in

preferences, which are made non-volatile by
saving them in a .ini file.
« The telephone system must provide a voice
response menu, going from a general menu to a
secondary menu »
« All useful parameters should be present in

preferences, which are made non-volatile by
saving them in a .ini file.
Requirements ≠ Design : Why ?
Neural diagnostics :
Requirement : “System must have a mini-keyboard with just
a start and a stop button”
– why ?
• Only operated by left hand
– why ?
• Both hands at the patient
– why ?
• Patient must be calmed and reassured
Neural diagnostics :
• System must have a mini-keyboard with just a start and a stop button
– why ?
• Only operated by left hand
– why ?
• Both hands at the patient
– why ?
• Patient must be calmed and reassured
Why not use speech recognition ??
Requirement : “It should be possible to start and stop the system with both
hands at the patient”
• Design excludes a lot of possibilities
• Requirements are context insensitive
• Different authors
• Requirements must be readable by users
Note : design issues may be added after

requirements are finalized
Domain vs. Product
Order
Order
info DB
Order
Audiology
CAD file
Pointcloud
Software
Production
Scanner Machine
Ear impression Hearing aid
Audiologist
Patient
Domain vs. Product
• Product
– Requirements can describe behavior
• Inner domain = product + direct
surroundings
– Requirements can describe supported activities
– Actor : first-level interaction with product
• Outer domain
– second-level interaction
The Goal-Design scale
• Goal level requirement
– e.g. “Device return rate must dimish from 25%
to 5%”
– Hard to accept for most software suppliers : not
their (sole) responsibility, too much risk
involved. (but …)
– Product is a concept, a strategy, not necessarily
a software. Supplier must be a specialist.
– Verification ? Validation ?
• Domain level requirement
– e.g. “The process must insure that components
fit prior to manufacturing”
– Outlines domain tasks to be performed, and
requires support for this task by the product
– Not restrictive to solution used (i.e. can use
customised COTS)
– Assumes supplier knows the domain
• Product level requirement
– e.g. “The software allows to automatically place the
selected component in the most optimal position, and to
manually adjust the position if necessary”
– Identifies a feature of the software
– Very specific on the product => harder to use COTS
– Assumes less domain knowledge
• Design level requirement
– e.g. “The component has three circular handles
that allow rotation around the three axes”
– Describes a product interface in detail
– Supplier usually better at designing interfaces
than customer. COTS is impossible.
– Useful if supplier doesn’t know domain at all
– Verification, validation ?
Choose which level ?
• Depends on supplier
– Management consultant
– Niche software supplier
– General software supplier
• How much responsibility for customer, how
much for supplier ?
Choose which level ?
• Goal level:
– include to improve understanding
– include so that the system can be verified against them
• Domain level :
– Include as requirements
– or included to explain purpose of requirement
• Design-level :
– Include as requirements
– Include as an example
Requirement document :
Contents
• Problem Statement
• Project overview
• Data requirements
• Functional requirements (level ?)
• Quality (non-func.) requirements
• Business rules
• Additional deliverables
• Managerial requirements (or : in contract)
• Clarification, context, background
Problem statement
• What is the purpose of the project/product ?
– e.g. : RSM intends to replace the entire manual
process of making hearing aid shells, including
canal impression, impression detailing, shell
design, and shell manufacturing, by a fully
digital process
• If it’s hard to write, everything in the
project will be hard.
Project overview
• Scope : what ? What not ?
• Business Goals/Objectives : What must be
Achieved ?
• Application Overview : Kind of App. ?
• User Demography : who will use ?
• Constraints : What IT must take into account
(Must run on a 386, ...)
• Assumptions : What customer will take care
of (e.g. training, deployment, ...)
Data requirements
• Database contents (not database structure)

• I/O formats
Functional requirements
• Many styles and formalisms are available
• A lot of functions are trivial : listing them is
more important than specifying them
• Keep data and functional reqs separate
• Domain level <-> Product level <-> Design
level
Quality requirements
• aka non-functional requirements
– Performance (speed, accuracy, capacity, …)
– Usability (user-friendly, efficient, training, ..)
– Maintenance (easy to change, …)
Additional Deliverables
• Documentation
• Hardware
• Services
– installing
– training
– maintaining (updates)
– converting data
Managerial requirements
• Often part of the project agreement, not the
requirements
– planning
– price and payment (fixed, T&M, variable)
– testing requirements
– legal responsibilities
– intellectual property
Requirements document :
finally …
• Add a “context”
– Customer background (company profile)
– Rationale of requirements (why important)
– Glossary, examples, diagrams, pics, sample
products,…
• Organize using a template
– part of standard process
– e.g. IEEE 830
The trouble with Requirements
docs
• Differences between written requirements and demand
• Too much work
• Off topic, wrong assumptions
• Too big
• Not adept to change
Extremes :
• No requirements (risk of solving the wrong problem)
• Requirements are an aim on its own (too expensive,
useless)
• One-person requirements (App will only work for him)
Prototypes
• UI-prototype
– Early implementation of the UI (without functionality)
– Delay until Finished-iteration
• Technical Prototypes
– Part of Design/Research
– Implement technically hard tasks early
– Can be done during requirements gathering to asses
feasability and risk.
Use Cases : Why ?
• What interests users ?
– System = black box
– Interactions between user and system are the
only importance
– Structurered, non-redundant, maintainable
document
Use Cases : What ?
• Definition : a use case describes sequences of
actions a system performs that yield an observable
result of value to a particular actor
• Design-level requirements
• Write detailed description of each user-system
interaction
• Show overview of interactions and participants in
a diagram
Use Case
Use Case Name :
Use
Sell Property
case
Iteration : Filled
Summary : System Context : The seller lists the property, a buyer

purchases the property, and the agents guides them
through the process and offers advice.
Basic Course of Events 1. Seller lists properties to sell

2. System responds by displaying these properties in
the property adds, and includes them in the search
engines.
3. Buyer selects an agent
4. System informs agent that buyer wants to use his
services
5. Buyer reviews properties by entering search criteria
6. System displays properties that match search criteria
7. …
Use Case : Text
• No implementation specific language
– no pseudo-code (IF, WHILE, …)
– no specific people (“manager”, not “Carl S.”)
– no specific user interface description (buttons,
menus,…)
– no IT jargon (TCP/IP, ODBC, …)
A use case is context-free

UML
• Unified Modeling Language (standardized
by the Object Management Group)
• Notation, not a methodology
• Extensible through stereotyping
• OO oriented
• de-facto standard (= good reason to use it
too)
Use Case Diagram
• … a UML diagram
• Describes interaction between
– actor and use case
– use case and use case
Use Case Diagram
Agent
Sell Property
Buyer
Seller
Use Cases : Actors
• Use cases show interactions that provide
value to actors
– Actors can be
• users
• other systems (Database)
• external events (time-out,...)
– Actors initiate all interactions
Associations
• Generalizations of actors
– Superactor interacts when all subactors interact
in the same way
– Subactor interacts when different from
superactor
employee
App. Engineer Developer

Associations
• Stereotype <<extend>>
<<extend>>
Enroll foreign student

Enroll student
• Stereotype <<include>>
<<include>>
Indicate plane
Planar project curve <<include>>
Planar cut object

Use Case Template
• Provides different entries of the use case
text
• Not standardized, but you should !
• Each entry should be meaningful and
unique
• Use Case ≈ 1-2 pages of text (speed-
readable)
Use Case Template : example
entries
• Use Case Name
• Use Case Iteration :
– façade, filled, focused, finished
• Use Case Summary : what does the use case
represent, in 1 sentence
• Author
• Date (for each iteration)
entries
• Actors
• Basic Course of Events :
– Steps taken by actors and system (alternatively) to
accomplish goal
– Focus on most common path (no exceptions, errors, or
alternative paths)
– If clarifying, include attachments with diagrams of
other kinds, calculations, …
• Related Business Rules
entries
• Alternative paths :
– other (less common) paths through the use case
– used to avoid IF-THEN clauses, and user
confusion
• Exception paths :
– Course of action taken if an error occurs
• Extension Points :
– where can an extending use case add
interactions ?
entries
• Triggers : when/why will actors enter this
use case
• Assumptions : what out-of-scope factors
must be true if this use case is to function
properly
• Pre-conditions : what must be true before
the interactions can start
• Post-conditions : what will be true after use
case was completed successfully (common
+ alternative paths)
Use Case : Increments/Iterations
• Facade = outline the project, split in parts
• Filled = deepen, write down details
• Focussed = narrow the scope
• Finished = complete and fine-tune
Iterations ≠ Phases
Steps to build a use case model
• Step 1 : Identify the actors
– Find everybody/everything that interacts with
the system
• Step 2 : Identify the use cases
– Find what the actor uses the system for
– Find what the actor needs to tell the system
– Find what the system needs to tell the actor
– Provide names and descriptions
Steps to build a use case model
• Step 3 : Identify Actor-Use Case relationships
– Which actor is involved in which use case ?
– Draw the UML diagram
• Step 4 : Fill the use cases
– Write the basic course of events
– Write alternate/exceptional flows
• Step 5 : Refine the use cases
– Add pre/post conditions
– Add detail
Scenarios
• Instance of a path
• Provides specific data
• Follows a specific path or exception
• Use :
– To illustrate use case functioning to the user
(validation)
– To provide test cases during testing
(verification)
Task Descriptions
• Structured text describing user tasks
• Domain level requirements
• Similar to use cases
– task = human and computer perform a common goal
together
– use case = what part is performed by computer ?
Task
use case
Human Computer
Task Descriptions
• Advantages :
– Easy validation and verification
– Domain level ( no detailed reqs necessary)
– Complex systems can be easily described
• Disadvantages
– Design is harder
Assignment
• Database for keeping track of company-
wide training
– Mission Statement : provide a system to
support the logistics involved in, and the
accounting of, training of company employees.
Assignment
• Some ideas :
– Employees can follow trainings. They often forget they
were invited or enrolled in a training.
– Trainers (=special employees or external companies)
organize trainings. They need to report to management
who took part.
– ISO9000 requires that trainings are budgetted and that
some kind of evaluation on the trainers is performed.
– Supervisors (“boss” of an employee) want to know
what an employee knows (was trained for) and what
not.
Assignment
• Write a requirements document
– using use cases
– using task descriptions
– using whatever else necessary

Softeng - Software Requirements Feb 2004

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Softeng - Software Requirements Feb 2004

Caricato da

Copyright:

Formati disponibili

Software Engineering

The Goal of Software

Software Development Process

The Waterfall Model

The Waterfall Model

The Waterfall Model

The Spiral Model

The Spiral Model

The Iterative Approach

The Iterative Approach

The Iterative Approach

The Iterative Approach

The Iterative Approach

Requirements in the Iterative

The Root Causes of Failure

The Root Causes of Failure

The Frequency of Requirements

High Cost of Requirements

High Cost of Requirements

The Requirements Problem : Key

Don’t expect you can specify it all

Problem : business changes, requirements too

We need requirements management

Requirements and design are different things

« When the user clicks the « select company »

« When the user clicks the « select company »

« All useful parameters should be present in

« All useful parameters should be present in

Why not use speech recognition ??

Note : design issues may be added after

• Database contents (not database structure)

Summary : System Context : The seller lists the property, a buyer

Basic Course of Events 1. Seller lists properties to sell

A use case is context-free

App. Engineer Developer

Enroll foreign student

Planar cut object

Potrebbero piacerti anche