Chapter 3 Requirements

Chapter 3: Requirements
Ronald J. Leach
Copyright Ronald J. Leach, 1997, 2009,

1
2014, 2015
Wrong Requirements

2
2014, 2015
What can go wrong?
• Requirements can be inconsistent
• Requirements can be incomplete
• Requirements can be set correctly for a
system that no one wants or will use

3
2014, 2015
What if requirements are
“wrong?”
• If requirements are inconsistent:
– No system can be built to meet these
requirements
– Any activity based on assumptions about these
inconsistent requirements must be redone
– Disaster!
– Fix requirements as early as possible
– Most other software activities are irrelevant

4
2014, 2015
What of requirements are wrong
• If requirements are incomplete:
• The problem is not too severe if the
requirements were modular
– A team experienced in the application domain is
likely to be able to fill in the missing requirements
– Additional effort and delays
– The system may be built wrong

5
2014, 2015
What of requirements are wrong
• If requirements are incomplete:
• The problem is severe if the requirements
were not modular
– A team not experienced in the application domain
will have great difficulty filling in the missing
requirements
– The system is almost certain to be built wrong

6
2014, 2015
Building the wrong system
• If the system’s requirements do not meet the
needs of known or supposed users
– Unlikely to be used or sold
– Why bother?

7
2014, 2015
Breakdown of sources of errors
Requirements Many
Design Somewhat fewer
Code Somewhat fewer still
Testing Somewhat fewer still
Relative cost to fix errors at different

life cycle phases
Requirements 1.0
Design 5.0
Code 10.0
Testing 30.0

8
2014, 2015
Requirements Elicitation

9
2014, 2015
Requirements Engineering Process

10
2014, 2015
In the very beginning …
• Identify customers, users (the stakeholders)
• Communicate with them
• …

11
2014, 2015
In the beginning …
Requirements must describe:
•Hardware platform
•Operating system
•Multiple hardware and operating systems
•File formats
•GUI, COTS, DBMS, …
•Delivery mechanism
•…
12
2014, 2015
In the middle …
• Specify versions
• Performance characteristics
• System resources needed
• System Functionality
• Details
• Details
• Details

13
2014, 2015
In the end …
• Complete, consistent requirements
• Build the system right
• Make sure you are communicating with
customers (prospective or surrogates) to build
the “right system”

14
2014, 2015
Requirements Traceability Matrix

15
2014, 2015
Why a RTM?
• To help determine if a requirement is testable
• To help project management keep track of the
status of the project

16
2014, 2015
Requirements Traceability Matrix
Number Requirement Design Code Test
1 Intel-based
2 Windows 8
3 Consistent with User

Interface of Windows 8
4 Graphical User Interface
5 Consistent With
Mystery 3.1
6 System One Size Only
7 <200 MB System, <500

MB Disk
8 Share Data with
Catchall 7.3
9 On-line Help Provided
10 Delivery on CD
11 Include Installation And

Decompression

17
2014, 2015
Can each of these requirements be
tested?
• Describe a simple test for each one
• If you can’t find a test, the requirement is too
vague

18
2014, 2015
What about more complicated
requirements?
• Most systems are far too complex to have this
simple sequential arrangement of
requirements
• Stepwise refinement, better numbering
systems to identify grouped requirements can
help

19
2014, 2015
Four general techniques
Use data abstraction and information hiding to
completely describe system functionality.
Regroup requirements to be consistent with
requirements and design of both existing and planned
systems.
Reuse requirements in order to reuse existing designs
and source code previously developed to meet these
requirements.
Automate the requirements engineering process.

20
2014, 2015
Information Hiding

21
2014, 2015
Information Hiding
• Information Hiding Principles
• Developed by Daniel and Orna Berry
• Journal of Systems & Software

22
2014, 2015
Information Hiding Principle 1
• Requirements must be modified and refined
until the system can be developed by software
designers and coders who are;
– familiar with the fundamental algorithms
of the application domain
– ignorant about the requirements
engineering process.

23
2014, 2015
Information Hiding Principle 1,
cont.
• The eventual requirements will be so
complete and unambiguous that
– the design will be clear
– the coding can be done easily by
implementing standard, well-known
algorithms.

24
2014, 2015
Information Hiding Principle 2
• The requirements must be modified and
refined until
– the system requirements can be
understood by requirements engineers who
are knowledgeable about requirements
engineering, but who know nothing about
the application domain.

25
2014, 2015
Information Hiding Principle 2,
cont.
• The eventual requirements will be so
complete and unambiguous that
– the requirements engineer will understand
them completely, even without knowledge
of the application domain.

26
2014, 2015
Requirements and Reuse

27
2014, 2015
Reuse-Driven Requirements
• A process that can help customers reduce
costs and still get the system they want.
• There may be existing components that meet
the customer’s essential requirements, but
might not meet all the requirements stated
initially.

28
2014, 2015
Reuse-driven requirements
1. Get requirements from customer.
2. If an existing system meets requirements, done.
3. If not, perform domain analysis
– Determine existing system closest to customer
requirements.
– Negotiate requirements with customer to
determine if agreement on a lower cost system
meeting fewer requirements.

29
2014, 2015
– If customer will not accept new proposed
solution with reduced requirements,
decompose system into subsystems.
– Use domain analysis classification scheme for
decomposition into subsystems.
– For each subsystem, produce existing new
subsystem that either matches subsystem
requirements or is closest to them.

30
2014, 2015
– Negotiate reduced subsystem
requirements with customer
– Allow selecting a subsystem with reduced
functionality.

31
2014, 2015
– Each negotiation with customer will include
detailed descriptions of the tradeoffs in
capability vs. reduced cost of system.
– Estimation of integration and maintenance
costs is essential at each stage.
– Continue the process of domain and system
decomposition as much as necessary.

32
2014, 2015
• The algorithm was quite detailed and required
intensive customer interaction.
• New code is to be written only as a last resort.
• COTS-only systems are the extreme case of this
process.
• Few models: (Waund, Ellis at Loral, Kontio, Basili
at Maryland, IMMACS project at NASA/Goddard).
• Barry Boehm has a related approach called "win-
win.”
• Highly useful in agile processes

33
2014, 2015
Applying this approach
• The process depends upon negotiation with a
customer.
• If there is no known customer, as is the case
with much commodity software, the process
won’t work.
• The process also does not apply to safety-
critical systems, in which requirements are
rarely negotiable.
• It can work in any other environment in which
the customer is highly motivated by cost.
34
2014, 2015
Summary
• Reuse-driven requirements is a process that can
help customers reduce costs and still get the
system they want.
• The basic idea is that there may be existing
components that meet the customer’s essential
requirements, but might not meet all
requirements stated initially.
• The process requires an existing trust relationship
with the customer.
• Systems engineering costs are high!
35
2014, 2015
Use-Cases in Requirements
Engineering

36
2014, 2015
Web Crawler Example
• The next two diagrams illustrate a simple
example of how an administrator would
interact with a web crawler to gather
information from a collection of websites in
order to provide for later analysis.

37
2014, 2015
38
2014, 2015
39
2014, 2015
Use-Cases
• Additional ones may be necessary for most
systems
– Including the major continuing software
development project

40
2014, 2015
Usability Requirements

41
2014, 2015
Bleser’s Guidelines
• Identify relevant guidelines.
• From the overall set of guidelines, select those
that pertain to the application.
• Narrow down the subset of pertinent
guidelines.
• Develop design rules from the guidelines.
• Allow for reasonable exceptions.

42
2014, 2015
A few more detailed guidelines
• Identify the attributes of user performance
that may be affected by the conflicting
guidelines (e.g., color discrimination, target
detection, speed of response).
• Weight the importance of those attributes for
overall system performance for this project.

43
2014, 2015
A few more detailed guidelines
• Using a numeric scale, rate the conflicting
guidelines for their expected effect on each
performance outcome.
• Multiply ratings by weights and sum the
products. Select the guideline with the higher
total.

44
2014, 2015
Specifying Requirements
by State Diagrams

45
2014, 2015
Chemical Reaction State Diagram

46
2014, 2015
State Table Function
Current State Input New State
1 B 2
2 250 3
3 R 4
4 300 5
5 H 5
5 300 7
5 anything else 6
6 250 5
7 anything but 400 8
7 400 9
8 P 9
8 S 1
9 Anything 9

47
2014, 2015
State Diagram Decision Table
Current State Input New State

1 B 2
2 if temp <= 250 3
3 R 4
4 if temp >= 300 5
5 H 5
5 if temp >= 300 7
5 if temp >= 400 9
5 anything else 6
6 if temp <= 250 5
7 anything but temp >= 400 8
7 if temp >= 400 9
8 P 9
8 S 1

48
2014, 2015
Ethical Analysis of Requirements

49
2014, 2015
Ethical Issue- Requirements are
incorrect
• Some computations are theoretically
impossible.
• Some interactions with different subsystems
are inconsistent within the software itself.
• Some interactions are inconsistent with
systems intended to be interoperable.
• Impossible performance demands
– execution time or space requirements.

50
2014, 2015
IEEE Code of Ethics (excerpt)
• To accept responsibility in making engineering
decisions consistent with the safety, health,
and welfare of the public, and to disclose
promptly factors that might endanger the
public or the environment;
• to avoid real or perceived conflicts of interest
whenever possible, and to disclose them to
affected parties when they exist;

51
2014, 2015
• to be honest and realistic in stating claims or
estimates based on available data;
• to maintain and improve our technical
competence and to undertake technological
tasks for others only if qualified by training or
experience, or after full disclosure of pertinent
limitations;

52
2014, 2015
• to seek, accept, and offer honest criticism of
technical work, to acknowledge and correct
errors, and to credit promptly the
contributions of others;

53
2014, 2015
What if you bring suspected
problems to a manager?
• The manager does not agree with your
analysis.
• The manager agrees with your analysis and
will ask the requirements team to fix the
problem.
• The manager seems to be ignoring the
problem, allowing a potentially serious
problem to occur.

54
2014, 2015
Metrics for Requirements

55
2014, 2015
Some Approaches
• Count the number of distinct requirements.
• Compute the sum over all requirements of the
“functionality” of each requirement.
• Matching the requirements to those of
existing systems that are to be reused.
• Compute the “size” of the interfaces to other
software systems to which the desired
software will be interoperable.
56
2014, 2015
Function Points (Albrecht)
• The number and type of user interactions.
• The number and type of interfaces to internal
files.
• The number and type of interfaces to external
files.
• The general perception of the difficulty of
programming in the application domain.

57
2014, 2015
Weights for Function Points
Simple Average Complex
External input or 3 4 6
files
External outputs or 4 5 7
reports
External queries or 3 4 6
responses
External interfaces to 7 10 15
other systems
Internal files 5 7 10
58
2014, 2015
Use this table for FPs
FP = count_total *(0.65 + sumfI /100)

59
2014, 2015
Another metric
• How many requirements can be met by simply
reusing a large-scale component or COTS
product?
– Remember that reuse of requirements and
related designs, code, test plans, etc. has the
highest payoff in reducing cost and effort

60
2014, 2015
The Requirements
Review

61
2014, 2015
Checklist for a Requirements
Review Meeting
• Presentation rehearsed.
• Time of presentation within allotted limits.
• Sufficient time is available for questions.
• People who can answer technical questions
are in attendance.
• Slides, transparencies, and multimedia
materials checked for accuracy and spelling.

62
2014, 2015
Checklist for a Requirements
Review Meeting
• Copies of slides and multimedia materials
available to all participants.
• Meeting room has all necessary equipment
• Network connectivity needed to control
presentation (including Bluetooth, infrared,
and ad-hoc networks) available.
• An attendance list with contact information.

63
2014, 2015
Requirements – Waterfall model
• Requirements should be complete, consistent,
and free of any ambiguities.
• The software design process should be ready
to begin.

64
2014, 2015
Requirements – Iterative models
• The next iteration should be able to continue
without delay.
• Requirements should be consistent and free
of any ambiguities.
• Any incompleteness should be resolvable in
the next iteration.
• Requirements should be more complete than
at the end of the previous iteration.
65
2014, 2015
Requirements – Iterative models,
cont.
• A software project manager wants his or her
project to produce software to be developed
efficiently and the final product to be of high
quality.
• Some inefficiency or detours during the
setting of requirements and the system’s
design are probably unavoidable.

66
2014, 2015
Requirements – Iterative models,
cont.
Managers hate unexpected surprises.
– Incoherent requirements review
presentations.
– Missing documentation.
– Obvious omissions.
– Customer angry because technical and other
issues raised earlier meetings were ignored.
– Logistical infrastructure, AV, too small room.

67
2014, 2015
Management Perspectives on
Requirements Reviews
• Relative certainty that the software will be
developed efficiently and the final product will
be of high quality.
• Some inefficiencies or detours during the
setting of requirements and the system’s
design are probably unavoidable.

68
2014, 2015
Managers hate unexpected
surprises
• Incoherent requirements review
presentations.
• Missing documentation.
• Obvious omissions.
• Angry customer because issues raised at an
earlier meeting were ignored.
• Missing logistical infrastructure
– audio-visual equipment or a too small room.
69
2014, 2015
Case Study of Management
Perspective on Requirements in
Agile Development

70
2014, 2015
Case Study Context
• Experienced team in the domain of spacecraft
control systems
• Most of the team had won an award for cost
savings, even while producing software of
very high quality

71
2014, 2015
Fundamental Assumptions
• The team is experienced in the application
domain and buys in to agile processes
• The team is talented
• Team members can work independently
• The team knows the capability and quality of
available large-scale components and COTS
products
• Management support using agile processes
72
2014, 2015
Team attitudes
• Avoided the “Not Invented Here Syndrome”
• Attitude projected was more of “I can't tell
you what I want, but I'll let you know when
you get there!”

73
2014, 2015
The Requirements
• Started out vague and broadly focused
• Selected a COTS product, LabView, to control
software
– LabView normally used to control experiments
– LabView had an international user base and was
unlikely to be discontinued
• Applied agile techniques to a large set of
systems

74
2014, 2015
Experience allowed decreased
time to gather requirements

75
2014, 2015
The Major Continuing Software
Development Project -

76
2014, 2015
• Several stakeholders develop a problem
statement after several iterations.
• Eliminate vague and unsustainable words
– Standard, as simple as possible, flexible enough,
should have a common interface, treated as
library requirements
• They produce some examples of how the
system should work.

77
2014, 2015
Requirements Traceability
• Create a preliminary RTM.
• If no test can be determined for a particular
requirement, it should be rewritten or
discarded.

78
2014, 2015
Sample designs of screens
Such mockups can help explain proposed systems

79
2014, 2015
Review
• Review the requirements

80
2014, 2015

Chapter 3 Requirements

Uploaded by

Copyright:

Available Formats

You might also like

Chapter 3 Requirements

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 3 Requirements

Uploaded by

Copyright:

Available Formats

Chapter 3: Requirements

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Design Somewhat fewer

Code Somewhat fewer still

Testing Somewhat fewer still

Relative cost to fix errors at different

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

3 Consistent with User

7 <200 MB System, <500

11 Include Installation And

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

7 anything but 400 8

Copyright Ronald J. Leach, 1997, 2009,

Current State Input New State

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,

Copyright Ronald J. Leach, 1997, 2009,