slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
User Requirements Phase Drawn from Sommerville and S. Lauesen , Software Requirements, Styles and Techniques , Ad PowerPoint Presentation
Download Presentation
User Requirements Phase Drawn from Sommerville and S. Lauesen , Software Requirements, Styles and Techniques , Ad

Loading in 2 Seconds...

play fullscreen
1 / 36

User Requirements Phase Drawn from Sommerville and S. Lauesen , Software Requirements, Styles and Techniques , Ad - PowerPoint PPT Presentation

  • Uploaded on

User Requirements Phase Drawn from Sommerville and S. Lauesen , Software Requirements, Styles and Techniques , Addisson Wesley, 2002. Overview. User requirements capture and analysis is an early phase of every lifecycle model.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'User Requirements Phase Drawn from Sommerville and S. Lauesen , Software Requirements, Styles and Techniques , Ad' - zonta

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

User Requirements PhaseDrawn from Sommerville and S. Lauesen, Software Requirements, Styles and Techniques, Addisson Wesley, 2002

  • User requirements capture and analysis is an early phase of every lifecycle model.
  • Capture means finding out what the user wants … using different dialog techniques … and documenting this.
  • Analysismeans studying thedocumentedrequirements for errors and technical consequences
  • Product: the system to be delivered
  • Inner domain: product + surrounding work area, immediate users, their activities, other systems
  • Outer domain: customers, “second-level users”, AKA business domain
  • Product I/O
  • Domain I/O
  • Product-level requirements
  • Domain-level requirements
  • Actor: human or external system that communicates with the product
  • Stakeholder: people who ensure the success of the project. (Not the same as actors, why?)

Outer or

Business Domain


Domain I/O


Product I/O




Inner Domain


scale of requirements responsibility
Scale of Requirements(responsibility)


1: what can we actually take responsibility for?

2: what is the right level of requirement?

the typical urd
The Typical URD
  • Introduction: including business goals
  • Limits of the system: scope and interfaces
  • Data requirements: data model + dictionary
  • Product functional requirements: function lists, feature reqs, process descriptions
  • Quality requirements: non-functional

Documentation standards: PSS-05, IEEE 830

types of requirements
Types of Requirements
  • Functional requirements: describe what the system does, in terms of input data, output date, error messages, etc.
  • E.g. a spreadsheet, a database, a word processor, 3D game, etc
types of requirements1
Types of Requirements

Non-Functional(AKA Quality) Requirements:

  • “everything else”
  • The product
  • The development process
  • The system environment
  • We can place these in a taxonomy (Sommerville) with a checklist function
  • See also:
    • McCall and Matsumoto (1980)
    • ISO 9126
    • IEEE 830 (software requirements specifications)






















requirements capture
Requirements Capture
  • An iterative dialog between
  • End-users Requirements


Using a variety of tools and techniques

why don t we just ask the customer
Why don’t we just ask the Customer?
  • Stakeholders may have difficulty expressing their needs, or may ask for a solution that doesn’t meet their needs.
  • Stakeholders can have conflicting demands
  • Users find it difficult to imagine new ways of doing things, or to imagine the consequences of what they ask for
  • A system that fulfills the requirements may not fulfill user expectations
  • Sometimes there are no users because a product is completely new
  • Demands and the environment change over time
capture techniques
Capture techniques

A good analyst:

  • knows many techniques,
  • knows when to use them and when not,
  • Combines and modifies techniques according to

specific needs.

  • Stakeholder analysis (small scale, who, what, why, risks, costs, solutions?)
  • (Group) interview (recorded, taped, filmed)
  • Observation (see also ethnography / immersive studies)
  • Task demo (“here’s how I usually …”)
  • Document studies (company info)
  • Questionnaires (large scale, capture statistics & opinions, open/closed questions)
  • Brainstorm (unstructured – anything goes)
  • Focus groups (structured)
  • Domain workshops (business process)
  • Design workshops (interface ideas)
  • Prototyping (product-level reqs., design-level reqs.)
  • Pilot experiments (COTS?)
  • Similar companies/ Related products
  • Ask suppliers (they know their customers)
example organizing a focus group
Example: Organizing a Focus Group

1. Invite participants: 6-18 people, all stakeholders represented, max 30% are suppliers

2. Open the meeting: present the topic, let people get to know each other and relax

3. Bad experiences: roundtable discussion of past experiences with similar products or work domains. Record issues on whiteboard. Record ideas on whiteboard. Facilitator makes sure no one dominates. Supplier staff are low key

focus group continued
Focus Group (continued)

4. Imagine the Future: Invite ideas, invite speculation. Ask: why/when do you want this? Record ideas.

5. List the issues: edit on the fly, regroup and organise, combine similar. Record issues.

6. Prioritize issues: Each stakeholder group picks top ten – but don’t prioritize within these to avoid conflict.

7. Review the lists: rountable comment, and close the meeting

requirements analysis and validation
Requirements Analysis and Validation
  • “Are we building the right product”?
  • i.e. will we build the product the customer truly wants to have? (at least at some point in time!)
  • Paradox: only the customer can determine this … but the customer is non-technical!
requirements analysis
Requirements Analysis
  • Analysis involves several types of checks and tests that can be carried out:
  • Validity
  • Consistency
  • Completeness
  • Realism
  • Verifiability
  • Problem: User may have incorrectly defined a functional requirements. All requirements must be checked for functional correctness
  • Methods:
    • Rapid prototype
    • Paper model
    • Animation/simulation
    • Check existing/historic data
    • Test case generation
    • URD reviews
    • System User Manual
  • Problem: User may state requirements that contradict each other (Common with many end-users!)
  • E.g. year + 1 > year

year is a 2-digit number

99 + 1 = 00 > 99 contradiction!

Simplified model of the Year 2000 Problem

  • Methods:
  • If requirements are formal use constraint solvers and/or CASE tools for automatic check
  • Manual check, unclear, error prone, combinatorial explosion!
  • Note: problem may not be solved by prototyping
  • Problem: user may have forgotten some requirements, leaving holes in the requirements document. These may possibly be solved arbitrarily … but possibly not!
  • Methods:
    • Rapid prototyping
    • URD reviews
    • Test case generation
    • Use cases analysis
    • Tables
    • Fault/ decision trees
realism feasibility
Realism (Feasibility)
  • Problem: User may express requirements that or not technically feasible (e.g. performance) or violate some non-functional requirement (e.g. legislative)
  • Methods:
    • Prototyping
    • Mathematical model/simulation (e.gqueueing theory)
    • URD reviews
    • External advice (e.g. lawyers)
  • Problem: Users may state requirements which can never be checked/verified,
  • E.g. “user interface must be user friendly and easy to use”
  • Contractual disputes may emerge
  • Methods:
    • Test case generation esp. acceptance tests
    • Usability metrics
usability fit for use ease of use
Usability = fit for use + ease of use

The five (ease of) usability factors (Schneiderman


  • Ease of learning
  • Task efficiency
  • Ease of remembering
  • Subjective satisfaction
  • Understandability

Some developers claim we cannot optimize all 5,

if so … which to prioritize?

security requirements
Security Requirements

While other requirements support use-cases ...

safety requirements prevent abuse-cases.

Customer has certain assets to be protected


We will examine security under risk

management later …

requirements capture languages
Requirements Capture Languages
  • Requirements need to be recorded as precisely as possible,
  • Therefore technical requirements languages are useful
  • Large variety of these in many styles
  • Wefirstconsiderstyles:merits and demerits
style natural language
Style: Natural Language

+ easily understood (esp. by end-user)

+ no technical training needed

+ very high-level/compact requirements

  • unclear/ ambiguous
  • debugging is difficult
  • no inherent structure
  • no tool support for validation (spell checker?)
style structured natural language
Style: Structured Natural Language

E.g. tables, decision trees, fault trees, data dictionaries

+ understood by end-user (sometimes)

+ small technical training

+ some structure (e.g. nouns, verbs, relations etc)

+ improve completeness issues

  • unclear/ ambiguous
  • lack of standards
  • little tool support
style graphical requirements language
Style: Graphical Requirements Language

e.g. UML, SDL, Petri Nets, etc

+ high-level/compact

+ quite or very precise

+ increasing tool support

+ often standardized / multiple vendors, courses, books, consultants

  • needs technical training
  • rarely understood by non-IT people and end-users
style formal specification
Style: Formal Specification

Logic: e.g. OCL, JML, VDM, Z, B, temporal logic

Ad-hoc: e.g. queuing theory, Markov chain

+ good tool support for validation problems

+ can be used to generate test cases, prove code correctness

+ extremely precise and accurate

  • Needs technical training
  • Poorly understood by end-users
  • Notation hard to read, overly detailed or low level
data modeling
Data Modeling
  • Data models describe data inside and outside the product
  • Good for experts, maybe difficult for end-users
  • Early models can survive all the way to coding
  • Good for completeness/consistency checking


  • Class Diagram (OO analysis)
  • Entity-Relationship diagram (Database theory)
  • Data dictionary: terms and meanings
  • Data expression: format and legal values. Use regular expressions or DTDs.
tables a structured style
Tables: a structured style
  • Advocated by David Parnas
  • Informal but structured style
  • Easily understood by end-users
  • Many formats, e.g. nested tables
  • Good for completeness and consistency check
  • Good for business rules

Requirement x. The product shall suggest the following discount

rates if a customer asks for a discount.