27/05/2014
Requirements
Acknowledgement SWEBOK
•
I went to SWEBOK (“Software Engineering Body of Knowledge”¶)for
some advice on this segment
• “The Software Requirements Knowledge
Area (KA) is concerned with the elicitation,
analysis, specification, and validation of
software requirements.
It is widely acknowledged within the software
industry that software engineering projects
are critically vulnerable when these activities
are performed poorly.”
– i.e. if you don’t get the requirements right there is no point in doing the rest of the work!
1
SWEBOK - http://www.swebok.org/ It is an IEEE organization that seeks
to define the curricula for “Software Engineering” courses.
2
SWEBOK – What is a
requirement?
Acknowledgement SWEBOK
• A software requirement
• “Software requirements express the needs
and constraints placed on a software product
that contribute to the solution of some realworld problem.”
– A property which must be exhibited in order to solve
some problem in the real world.
– It must be verifiable
• There isn’t much point defining a requirement if you can’t
determine whether the system meets the requirement!
– Typically will have
• a priority rating
– enables trade-offs in the face of finite resources
• a status value
– enables project progress to be monitored.
• A unique identifier
•
Needs ~ functional requirements
Constraints ~ non-functional requirements
– Permits tracking of requirements throughout project
(SWEBOK continues with definitions of functional/ non-functional requirement
etc)
3
4
SWEBOK – requirements process
SWEBOK – Process actors
• Requirements process model
•
– SWEBOK emphasises that “requirements” is not a separate
process conducted before the rest of the software life-cycle
but does continue throughout (a view consistent with RUP)
– “Requirements” have to be “managed” – management has
several aspects, including
Stress on the interdisciplinary nature of the requirements process –
identifying participants
– Users:
• those who will operate the software; often a heterogeneous group comprising
people with different roles and requirements.
– Customers:
•
• Requirements need version management just as code does (so
one should use tools that are adaptations of applications like
subversion)
• It must be possible to trace the links between requirements and
the software (and other elements) that are created to realize
those requirements
– Requirements process needs to be configurable for different
types of project
5
those who have commissioned the software or who represent the software’s
target market.
– Market analysts:
• A mass-market product will not have a commissioning customer, so marketing
people are often needed to establish what the market needs and to act as proxy
customers.
– Regulators:
•
Software in many domains must comply with the requirements of the regulatory
authorities.
– Software engineers:
• These individuals have a legitimate interest in profiting from developing the
software by, for example, reusing components in other products. If, in this
scenario, a customer of a particular product has specific requirements which
compromise the potential for component reuse, the software engineers must
carefully weigh their own stake against those of the customer.
6
1
27/05/2014
SWEBOK – Requirements
elicitation
SWEBOK – Requirements
elicitation (“capture”, “discovery”, “acquisition”)
• Requirements elicitation is concerned with
where software requirements come from and
how the software engineer can collect them.
It is the first stage in building an
understanding of the problem the software is
required to solve.
It is fundamentally a human activity, and is
where the stakeholders are identified and
relationships established between the
development team and the customer.
• “One of the fundamental tenets of good
software engineering is that there be
good communication between software
users and software engineers.”
XP-ers and RUP-ers would both agree –
the XP-ers might possibly say that this communication is all you
need.
7
8
Do we have requirements?
SWEBOK – Requirements sources
• If you are an XP player, then most of the rest of this
discussion will seem absurd.
• “Requirements have many sources in typical
software, and it is essential that all potential
sources be identified and evaluated for their
impact on it.”
– All this “nonsense” about verification of requirements, checks
for consistency, verifiability, reviews …
• XP style is really like a sequence of little related
projects – with maybe just one more requirement
being added at a time
– OK for smallish things – WWW form-processing etc – where
your tame user (the one you have locked down so that you
can always discuss things with a user) develops additional
requirements by using partially implemented systems
– Not much good for larger, more critical (safety critical,
business critical) applications
– Goals (“business concern” or “critical success
factor”)
– Domain knowledge.
– Stakeholders
– The operational environment.
– The organizational environment
Oddly – at this point SWEBOK doesn’t mention regulatory sources of requirements.
– (so, add “Regulatory organisations” to SWEBOK
list)
9
10
SWEBOK – Requirements sources
Domain knowledge
• “Requirements have many sources in typical
software, and it is essential that all potential sources
be identified and evaluated for their impact on it.”
• Quite often, an organisation will recruit a science
graduate, engineering graduate, or maths-finance
graduate rather than a CS person to develop
specialised software
– Goals (“business concern” or “critical success factor”)
• overall, high-level objectives of the software.
• the motivation for the software, often vaguely formulated.
• Need to pay particular attention to assessing the value (relative
to priority) and cost of goals; a feasibility study is a relatively
low-cost way of doing this.
– Domain knowledge.
• The software engineer needs to acquire, or have available,
knowledge about the application domain. This enables them to
infer tacit knowledge that the stakeholders do not articulate,
assess the trade-offs that will be necessary between conflicting
requirements, and, sometimes, to act as a “user” champion.
– Although software may be quite complex, it’s the domain
knowledge that matters more
– In past experience, the organisation has found it easy to
train the domain-specialist so that he/she can write adequate
code; training the CS grad in the domain was less practical
– …
11
12
2
27/05/2014
SWEBOK – Requirements sources
• “Stakeholders
• Much software has proved unsatisfactory because it has stressed the
requirements of one group of stakeholders at the expense of those of
others. Hence, software is delivered which is difficult to use or which
subverts the cultural or political structures of the customer organization.
The software engineer needs to identify, represent, and manage the
“viewpoints” of many different types of stakeholders.
• The operational environment.
SWEBOK – Requirements
elicitation techniques
• Techniques for getting human stakeholders to
articulate their requirements.
• Difficult:
– Users
• may have difficulty describing their tasks,
• may leave important information un-stated,
• may be unwilling or unable to cooperate.
• Requirements will be derived from the environment in which the
software will be executed. These may be, for example, timing
constraints in real-time software or interoperability constraints in an
office environment. These must be actively sought out, because they
can greatly affect software feasibility and cost, and restrict design
choices.
• The organizational environment.
• Software is often required to support a business process, the selection
of which may be conditioned by the structure, culture, and internal
politics of the organization. The software engineer needs to be
sensitive to these, since, in general, new software should not force
unplanned change on the business process.
• “Elicitation is not a passive activity;
even if cooperative and articulate
stakeholders are available, the software
engineer has to work hard to elicit the right
information.”
13
14
SWEBOK – Requirements
elicitation techniques
SWEBOK – Requirements
elicitation techniques
• Principal Elicitation Techniques
• Principal Elicitation Techniques
–
–
–
–
–
– Interviews,
Interviews
Scenarios
Prototypes
Facilitated meetings
Observation.
• The “traditional” means of eliciting requirements.
Need to understand
– the advantages and limitations of interviews
– how they should be conducted.
– Scenarios
• a means for providing context to the elicitation of user requirements.
• allow the software engineer to provide a framework for questions about
user tasks by permitting “what if” and “how is this done” questions to be
asked.
• The most common type of scenario is the use case.
– Prototypes,
• a tool for clarifying unclear requirements.
• They can act in a similar way to scenarios by providing users with a
context within which they can better understand what information they
need to provide.
15
SWEBOK – Requirements
elicitation techniques
16
SWEBOK - Requirements Analysis
– Facilitated meetings.
• Achieve a summative effect whereby a group of people can
bring more insight into their software requirements than by
working individually. .
• Another advantage is that conflicting requirements surface early
on in a way that lets the stakeholders recognize where there is
conflict.
• Need to be handled carefully (hence the need for a facilitator)
otherwise can have problems like:
– critical abilities of the team are eroded by group loyalty,
– or requirements that reflect the concerns of a few outspoken
people are favored to the detriment of others.
– Observation.
• Requirements Analysis is concerned with
the process of analyzing requirements to:
– Detect and resolve conflicts between
requirements
– Discover the bounds of the software and how
it must interact with its environment
– Elaborate system requirements to derive
software requirements
• Software engineers learn about user tasks by immersing
themselves in the environment and observing how users interact
with their software and with each other.
– relatively expensive,
– instructive because they illustrate that many user tasks and
business processes are too subtle and complex for their actors to
describe easily.
17
18
3
27/05/2014
SWEBOK – picky terminology
SWEBOK – Requirements
Classification
• System Requirements and Software
Requirements
• Requirements can be classified on a number of
dimensions including:
– System: “An interacting combination of elements to
accomplish a defined objective. These include hardware,
software, firmware, people, information, techniques, facilities,
services, and other support elements,”
• System requirements
– The requirements for the system as a whole
• user requirements,
• requirements of other stakeholders (such as regulatory
authorities),
• requirements without an identifiable human source.
– Whether the requirement is functional or nonfunctional
– Whether the requirement is derived from one or more highlevel requirements or an emergent property or is being
imposed directly on the software by a stakeholder or some
other source.
– Whether the requirement is on the product or the process.
– The requirement priority.
• common a fixed-point scale : as mandatory, highly desirable,
desirable, or optional
• has to be balanced against the cost of development and
implementation.
• “In a system containing software components,
software requirements are derived from system
requirements.”
19
SWEBOK – Requirements
Classification
20
SWEBOK – Conceptual Modeling
– The scope of the requirement.
• Some requirements, particularly certain non-functional ones,
have a global scope in that their satisfaction cannot be
allocated to a discrete component.
• A requirement with global scope may strongly affect the
software architecture and the design of many components,
whereas one with a narrow scope may offer a number of design
choices and have little impact on the satisfaction of other
requirements.
– Volatility/stability.
• Some requirements will change during the life cycle of the
software, and even during the development process itself.
• It is useful if some estimate of the likelihood that a requirement
change can be made.
• Flagging potentially volatile requirements can help the software
engineer establish a design which is more tolerant of change.
• Conceptual Modeling
– The development of models of a real-world
problem is key to software requirements analysis.
Their purpose is to aid in understanding the
problem, rather than to initiate design of the
solution.
– conceptual models comprise models of entities
from the problem domain configured to reflect their
real-world relationships and dependencies.
– Several kinds of models can be developed. These
include data and control flows, state models, event
traces, user interactions, object models, data
models, and many others.
21
22
SWEBOK – Conceptual Modeling
So what are they suggesting
• Conceptual Modeling
• They are suggesting that some of the modeling, as
discussed earlier, is really a part of the
“requirements” process
• Think about those
– “The development of models of a real-world problem is key
to software requirements analysis.”
Their purpose is to aid in understanding the problem, rather
than to initiate design of the solution.
– Conceptual models comprise models of entities from the
problem domain configured to reflect their real-world
relationships and dependencies.
– Several kinds of models can be developed
•
•
•
•
data and control flows,
state models,
user interactions,
data models.
–
–
–
–
(Business) Activity Diagrams
Communication diagrams (process level)
Deployment diagrams
Interaction overview diagrams
when you get to draw one of these you almost always
encounter issues that you had not thought about!
So doing this modeling immediately feeds back into
the requirements elicitation process.
23
24
4
27/05/2014
Further
Feedback loops
• They also suggest that your initial
planning of database tables (data
models) will have a strong feedback into
requirements clarification.
• Storyboard modeling of possible user
interactions with the proposed system
again feedback into the requirements
elicitation and refinement
Requirements
High level modeling:
Business Activity Diagram
Process Communication Diagram
Deployment Diagram
Persistent data identification
User Interface Storyboarding
Requirements
elicitation
More questions!
25
26
Thinking about persistent
data this early? !
Early storyboarding of UI
• SWEBOK advice to think about persistent
data this early in process is unusual
• SWEBOK advice to think UI this early in process is
unusual
– But it’s probably right.
– Role here is that it will prompt stakeholders to clarify issues
– But it’s probably right.
– In most applications, data persistence is such an
important part of the overall system that early
consideration is warranted.
• Unstated assumptions –
– “but of course you would first have to verify that user was in appropriate group to use this
feature” (never having mentioned user sub-groups before – because they thought you’d
just know them)
• Additional options
• Related but previously unmentioned “use cases”
27
28
SWEBOK and RUP
SWEBOK - modeling
• SWEBOK’s feedback loops fit in well with RUP’s idea
of the “requirements” stage lasting well into
elaboration and not being all completed in inception
• “Formal modeling using notations based
on discrete mathematics, and which are
traceable to logical reasoning, have
made an impact in some specialized
domains.
These may be imposed by customers or
standards or may offer compelling
advantages to the analysis of certain
critical functions or components.”
29
30
5
27/05/2014
SWEBOK – Architectural Design
and Requirements allocation
SWEBOK – Requirements
negotiation
• Architectural Design and Requirements
Allocation
• Requirements Negotiation (or “conflict resolution.”)
– Resolving problems with requirements where conflicts occur:
– Architectural design is the point at which the requirements
process overlaps with software or systems design and
illustrates how impossible it is to cleanly decouple the two
tasks.
– In many cases, the software engineer acts as software
architect because the process of analyzing and elaborating
the requirements demands that the components that will be
responsible for satisfying the requirements be identified.
This is requirements allocation – the assignment, to
components, of the responsibility for satisfying requirements.
– It is unwise for the software engineer to make a unilateral
decision, and so it becomes necessary to consult with the
stakeholder(s) to reach a consensus on an appropriate
trade-off.
– It is important for contractual reasons that such decisions be
traceable back to the customer.
31
32
• between two stakeholders requiring mutually incompatible
features,
• between requirements and resources,
• or between functional and non-functional requirements.
SWEBOK – Requirements
specification
SWEBOK – System Definition
Document
• Requirements Specification
• System Definition Document
– For most engineering professions, the term “specification”
refers to the assignment of numerical values or limits to a
product’s design goals.
– Software is different. It has a large number of requirements,
and the emphasis is shared between performing the
numerical quantification and managing the complexity of
interaction among the large number of requirements. So,
“software requirements specification” typically refers to the
production of a set of documents for review and approval
– Three different types of documents may be produced:
• system definition,
• system requirements,
• software requirements.
– This document records the system requirements
• Defines the high-level system requirements from the domain
perspective.
• It is intended for the system’s users/customers (marketing may
play these roles for market-driven software), so its content must
be couched in terms of the domain.
• Lists the system requirements along with background
information about the overall objectives for the system, its
target environment and a statement of the constraints,
assumptions, and non-functional requirements.
• May include conceptual models designed to illustrate the
system context, usage scenarios and the principal domain
entities, as well as data, information, and workflows.
This is the “Preliminary User Manual” of your CSCI321 project
XP-ers will be laughing; they don’t believe in the need for any of this stuff
33
34
SWEBOK – System Requirements
Specification
SWEBOK – Software
Requirements Specification
• System Requirements Specification
• Software Requirements Specification
– “Developers of systems with substantial software
and non-software components, a modern airliner,
for example, often separate the description of
system requirements from the description of
software requirements.
In this view, system requirements are specified,
the software requirements are derived from the
system requirements, and then the requirements
for the software components are specified.”
35
– Software requirements specification establishes the basis for
agreement between customers and contractors or suppliers
(in market-driven projects, these roles may be played by the
marketing and development divisions) on what the software
product is to do, as well as what it is not expected to do.
For non-technical readers, the software requirements
specification document is often accompanied by a software
requirements definition document.
– Software requirements specification permits a rigorous
assessment of requirements before design can begin and
reduces later redesign.
It should also provide a realistic basis for estimating product
costs, risks, and schedules.
– Organizations can also use a software requirements
specification document to develop their own validation and
verification plans more productively.
This is the “Preliminary Technical Manual” of your CSCI321 project
36
6
27/05/2014
SWEBOK – Software
Requirements Specification
SWEBOK – Software
Requirements Specification
•
Software requirements specification provides an informed basis
for transferring a software product to new users or new machines.
Finally, it can provide a basis for software enhancement.
•
Software requirements are often written in natural language, but,
in software requirements specification, this may be supplemented
by formal or semi-formal descriptions.
Selection of appropriate notations permits particular requirements
and aspects of the software architecture to be described more
precisely and concisely than natural language.
The general rule is that notations should be used which allow the
requirements to be described as precisely as possible.
This is particularly crucial for safety-critical and certain other
types of dependable software.
However, the choice of notation is often constrained by the
training, skills and preferences of the document’s authors and
readers.
• A number of quality indicators have been developed which
can be used to relate the quality of software requirements
specification to other project variables such as cost,
acceptance, performance, schedule, reproducibility, etc.
Quality indicators for individual software requirements
specification statements include imperatives, directives,
weak phrases, options, and continuances.
Indicators for the entire software requirements specification
document include size, readability, specification, depth, and
text structure.
• IEEE has a standard, IEEE Std 830 [IEEE830-98], for the
production and content of the software requirements
specification.
Also, IEEE 1465 (similar to ISO/IEC 12119) is a standard
treating quality requirements in software packages.
(IEEE1465-98)
37
38
SWEBOK – Requirements
Validation
SWEBOK – Requirements
Validation
• Requirements validation
• Requirements validation
– The requirements documents may be subject to
validation and verification procedures.
• The requirements may be validated to ensure that the
software engineer has understood the requirements, and it
is also important to verify that a requirements document
conforms to company standards, and that it is
understandable, consistent, and complete.
– Formal notations offer the important advantage of permitting
the last two properties to be proven.
– Different stakeholders, including representatives of the
customer and developer, should review the
document(s).
– Requirements documents are subject to the same
software configuration management practices as the
other deliverables of the software life cycle processes.
– It is normal to explicitly schedule one or more
points in the requirements process where the
requirements are validated. The aim is to pick
up any problems before resources are
committed to addressing the requirements.
Requirements validation is concerned with the
process of examining the requirements
document to ensure that it defines the right
software (that is, the software that the users
expect).
39
40
SWEBOK – Requirements Reviews
SWEBOK - Prototyping
• Requirements Reviews
• Prototyping
– The most common means of validation is by
inspection or reviews of the requirements
document(s).
A group of reviewers is assigned a brief to look for
errors, mistaken assumptions, lack of clarity, and
deviation from standard practice.
The composition of the group that conducts the
review is important (at least one representative of
the customer should be included for a customerdriven project, for example), and it may help to
provide guidance on what to look for in the form of
checklists.
Some of these points were mentioned in the overview of testing weeks ago
41
– A common means for validating the software engineer’s
interpretation of the software requirements, as well as for
eliciting new requirements.
– The advantage of prototypes is that they can make it easier
to interpret the software engineer’s assumptions and, where
needed, give useful feedback on why they are wrong.
• For example, the dynamic behavior of a user interface can be
better understood through an animated prototype than through
textual description or graphical models.
– There are also disadvantages including the danger of users’
attention being distracted from the core underlying
functionality by cosmetic issues or quality problems with the
prototype
• Suggestion is to use prototypes which avoid software, e.g. flipchart-based mockups.
42
7
27/05/2014
SWEBOK – Model validation
SWEBOK - Acceptance tests
• Model Validation
• Acceptance Tests
– (Just a suggestion that one “validates” the models created)
– If formal specification notations are used, it
is possible to use formal reasoning to
prove specification properties.
G. Pollice: How many times do software engineers actually take time out to prove
a program is correct? Almost never. Such formal methods may help us sharpen
our logic, but we almost never apply them in the real world.
– An essential property of a software requirement is
that it should be possible to validate that the
finished product satisfies it. Requirements which
cannot be validated are really just “wishes.”
An important task is therefore planning how to
verify each requirement. In most cases, designing
acceptance tests does this.
– Identifying and designing acceptance tests may be
difficult for non-functional requirements. To be
validated, they must first be analyzed to the point
where they can be expressed quantitatively
43
44
SWEBOK – Practical
considerations
Terminology?
• Strange
• Normally “verify” is supposed to mean “test to
see whether a system meets its
specification”.
While “validate” is supposed to mean “test to
see whether a system meets its users needs”
• I would have thought they should have been
“verifying” whether the system met its
requirement rather than “validating”
45
• The SWEBOK coverage of Requirements
touches next on some practical
considerations.
• Mostly this is re-iterating earlier points like the
iterative nature of the requirements process
and the need for “change management”
systems to keep track of changes to
requirements.
• Requirements tracing is an important “new”
aspect
46
The trouble with SWEBOK …
SWEBOK – Requirements tracing
• Requirements Tracing
– Requirements tracing is concerned with recovering the
source of requirements and predicting the effects of
requirements.
– Tracing is fundamental to performing impact analysis when
requirements change.
– A requirement should be traceable backwards to the
requirements and stakeholders which motivated it (from a
software requirement back to the system requirement(s) that
it helps satisfy, for example).
– Conversely, a requirement should be traceable forwards into
the requirements and design entities that satisfy it (for
example, from a system requirement into the software
requirements that have been elaborated from it, and on into
the code modules that implement it).
47
48
8
27/05/2014
But – “How do you ‘do
requirements’?”
SWEBOK
• It made a few good points
– “Requirements” must be verifiable
– Requirements must be “managed” – version
controlled etc
– Elicitation of requirements is primarily a humancommunication and not a technical problem.
– Regard those early modeling efforts (Activity
diagram etc) as part of the requirements effort
– Remember the importance of traceability of
requirements
–…
• What we want is something that is
prescriptive, operational –
this is how do you “do requirements”
• Any offers?
• But its style is declarative, didactic
49
50
Do requirements
How to “do requirements”
RUP “Requirements Workflow”
Rational and IBM at least make an effort to say how!¶
51
¶Strangely, it seems that the only way to do anything is to buy another extension package for Rational Rose
Do requirements
52
Do requirements
A workflow to guide us in getting
requirements!
But the Rational/IBM stuff is a
little more prescriptive than that
• Initially so encouraging
• Things to read in future:
–
• Then I read it
– Do
–
• Do
–
– Understand stakeholder needs
–
• Until (“addressing the right problem”)
• Define the system
• Manage the scope
–
–
– Until (! “can’t do all the work”)
– Refine the definition
– Exit
–
–
• Help! I am stuck in a (doubly) infinite loop (“I don’t think I’ll
ever understand what these guys really want, and even if I did understand
what’s needed it doesn’t seem that I could ever build it with available
resources”)
53
–
Requirements: An introduction
http://www.ibm.com/developerworks/rational/library/4166.html
Form feeds function: The role of storyboards in requirements elicitation
http://www.ibm.com/developerworks/rational/library/dec05/krebs/index.html
Dissecting business from software requirements
http://www.ibm.com/developerworks/rational/library/aug05/krebs/
Capturing Architectural Requirements
http://www.ibm.com/developerworks/rational/library/4706.html
Strategies for software development project success
http://www.ibm.com/developerworks/rational/library/nov05/begic/index.html
Requirements management practices for developers
http://www.ibm.com/developerworks/rational/library/2787.html
Supporting Iterative Development Through Requirements Management
http://www.ibm.com/developerworks/rational/library/2830.html
Managing use-case detail
http://www.ibm.com/developerworks/rational/library/4034.html
What, no supplementary specification?
http://www-128.ibm.com/developerworks/rational/library/3975.html
54
9
27/05/2014
Do requirements
Do requirements
A first overview – Scott McEwan
So “Understand the stakeholder needs”
• This overview gives a simple sequence
of steps to follow plus a little general
advice
55
Do requirements
56
Do requirements
Needs, features, requirements
Needs
• Start by distinguishing “needs”, “features”, and
“requirements”.
• Stakeholder needs
– part of the problem domain,
– describe what stakeholders require for a successful project
• help improve or lower the cost of a business process,
• increase revenue,
• meet regulatory or other obligations.
• Documenting stakeholder needs involves identifying,
understanding, and representing different viewpoints.
– Often, users and stakeholders don't know how to solve the
entire problem but are experts at explaining what they need
to do their job better.
– Each stakeholder sees the problem from a different
perspective.
• You must understand the needs of all stakeholders in
order to understand the entire problem domain.
Requirements: An introduction; Scott McEwen
57
Do requirements
58
Do requirements
For needs, do …
Features
1.
• A feature is a service that the system
provides to fulfil one or more
stakeholder needs.
• Needs are part of the problem domain,
and features are part of the solution
domain.
• It is critically important to fully
understand the problem domain before
deciding on a solution.
Identify and recruit at least one representative from
each stakeholder class who will speak for the entire
class.
–
2.
Elicit needs from stakeholders
–
–
–
–
3.
Document your list of stakeholders so that everyone
knows who is representing each class.
one-on-one meetings,
questionnaires,
storyboarding,
Facilitated meetings.
After you have defined stakeholder needs, translate
them into a set of distinct system features.
Uhm – McEwan’s point-2 is a bit weak; we will need that elaborated
59
60
10
27/05/2014
Do requirements
Do requirements
Stakeholders identifying features
Try to keep requests as “needs”
• Sometimes, stakeholders specify features rather than
needs
• McEwan makes a further argument for identifying
needs – a single feature may satisfy multiple needs.
– Example:
• “We need a system that sends secure emails among all
members of the marketing team’s discussion group”
• (They’ve decided on a secure group email system)
• The need – “we want all group members to be able to
participate in discussions of marketing strategies – of course
these discussions should only be visible to our group members”
• Given that need, you could pick other implementations such as
a Wiki accessed via the web and subject to password controls,
or a discussion document on an access controlled subversion
server.
• Stakeholders who have had some light weight IT
training (most Business Systems students these
days!) are particular prone to request features rather
than needs.
61
Do requirements
62
Do requirements
Features to Requirements
Features to Requirements
• Move deeper into the solution domain by analyzing
and capturing the system requirements
• Two categories of Requirements: functional
requirements and non-functional.
– ...a software capability that must be met or possessed by a
system or a system component to satisfy a contract, standard,
or desired feature.
– Functional requirements
• A complete description of how the system will function from the
user's perspective.
• They should allow both business stakeholders and technical
people to walk through the system and see every aspect of how
it should work -- before it is built.
• Requirements must represent either:
– Contract obligations
– Standards
– Desired needs and features
– Non-functional requirements
• dictate properties and impose constraints on the project or
system.
63
Do requirements
64
Do requirements
Software Requirements
Specification Document
Software Requirements
Specification Document
3. Consistency.
• Software Requirements Specification document:
1. Lack of ambiguity.
– The software development team will be unable to produce a
product that satisfies users' needs if one or more requirements
can be interpreted in multiple ways.
2. Completeness.
– In the beginning of your project, you should not expect to know
all the system requirements in detail; the development team
should not waste time trying to specify things that are bound to
evolve.
As the project proceeds, however, you should keep your
Software Requirements Specification document up to date; as
you gain more knowledge about the system, the specification
document should grow more complete.
– You cannot build a system that satisfies all requirements if two
requirements conflict or if the requirements do not reflect
changes that were made to the system during the iterative
development and functionality testing.
4. Traceability.
– The team should track the source of each requirement,
whether it evolved from a more abstract requirement, or a
specific meeting with a target user.
5. No design information.
– As long as requirements address external behaviors, as
viewed by users or by other interfacing systems, then they are
still requirements, regardless of their level of detail.
However, if a requirement attempts to specify particular
subcomponents or their algorithms, it is no longer a
requirement; it has become design information.
3. …
65
66
11
27/05/2014
Do requirements
Do requirements
Functional requirements
Use cases
•
• Use cases
To document functional requirements
you must capture three categories of
information:
– Define a step-by-step sequence of actions between the user
and the system.
– Are easier to create, read, and understand than traditional
functional specifications.
– Show how the system will work from the users' perspective
rather than the system's perspective.
– Force us to think about the end-game: What is the user trying
to accomplish by using the system?
– Require us to define how the system should work, step-bystep.
– Provide an excellent basis for building test cases and helping
to ensure that these are built before the code is written.
– Provide a common requirements "language" that's easy for
stakeholders, users, analysts, architects, programmers, and
testers to understand.
1. Use cases
2. Functional capabilities
3. Business rules
67
Do requirements
68
Do requirements
Functional requirements
continued
Use cases
• Capture use cases using a standard template that
contains all the components of a complete
specification:
–
–
–
–
–
–
–
–
–
–
• Functional capabilities
– Define what specific action the system should take
in a given situation.
– Relate directly to a specific use case or apply
globally for the entire system.
a use case diagram,
primary and assisting actors,
triggering events,
use case descriptions,
preconditions, post conditions,
alternative flows,
error and exception conditions,
risks and issues,
functional capabilities,
and business rules.
• Business rules
– State the condition under which a use case is
applicable and the rule to be applied.
– Can be directly related to a specific use case or
defined globally for the entire system.
69
Do requirements
70
Do requirements
Capturing non-functional
requirements
Non-functional requirements
• Non-functional requirements are attributes
that either the system or the environment
must have.
Such requirements are not always in the front
of stakeholders' minds, and often you must
make a special effort to draw them out.
• Five categories:
– Usability
• Describes the ease with which the system can be learned or used
– Reliability
• Describes the degree to which the system must work for users.
Specifications for reliability typically refer to availability, mean time
between failures, mean time to repair, accuracy, and maximum
acceptable bugs.
– Performance
• Specifications typically refer to response time, transaction throughput,
and capacity.
– Supportability
• Refers to the software's ability to be easily modified or maintained to
accommodate typical usage or change scenarios.
– Security
• Refers to the ability to prevent and/or forbid access to the system by
unauthorized parties
“Drawing out” non-functional requirements – sounds as pleasant as drawing teeth.
We will need this clarified.
71
72
12
27/05/2014
Do requirements
Do requirements
Scott McEwan overview
Cross-referencing requirements
• Kind of prescriptive
• Bit vague in places
• In simple systems, requirements can be almost independent
– E.g. the requirements for a web site that has “find courses”, “enroll
in course”, “view library books” operations are essentially
independent;
– “Elicit needs from stakeholders”
– “draw out non-functional requirements”
– “Functional capabilities” “Business rules”
• In more complex systems, you are likely to find relations
between different requirements
• It may be useful to create a cross-reference matrix illustrating
interdependencies.
• The “Needs/Features/Requirements”
approach is probably helpful
• Could help to have a few more “checklists”
R1
R2
R3


R4
R5
R1
R2
– Things to do when eliciting requirements
– Things to look for when reviewing the lists of
requirements that one has generated.

R3
R4
R5

73
Do requirements
74
Do requirements
Checklists for requirements
Checklists for requirements
• Another of those Rational/IBM papers suggests the following
“requirements attributes” should be present:
Priority
The priority of the
requirement within an
iteration.
High, medium, low
Description
Values
Customer Priority
The importance of the
requirement to the customer.
High, medium, low
Planned Iteration
The iteration in which the
requirement is slated for
implementation.
E1, E2 ... C1, C2 ...
(Note: E=Elaboration
iteration;
C=Construction iteration)
Risk
Rating of the risk the
requirement places on the
project.
High, medium, or low
Or calculated from
severity*probability
Architectural Impact
An actual iteration attribute
has priority over a planned
iteration attribute.
E1, E2 ... C1, C2 ...
The type of impact the
requirement has on the
Architecture
None, extends, modifies
Actual Iteration
Stability
Status
Current status of the
requirement.
Proposed, approved,
incorporated, verified
An indication of the
requirement's likelihood to
change
Hard -- not likely to change
Neutral -- unknown
Soft -- likely to change
75
Do requirements
76
Do requirements
Another checklist
Eliciting requirements
• This (partial) checklist is based on one proposed by
Pressman in his “Software Engineering” text
• How?
It depends to some degree on the project.
– Are the requirements stated clearly? Can they be
misinterpreted?
– Is the source (person, regulation, document) of the
requirement identified? Has the requirement been examined
by/against the original source?
– Is the requirement bounded using quantitative terms?
– Are requirements inter-related? Are these relationships
displayed clearly in a cross-reference matrix?
– Does the requirement violate domain constraints?
– Is the requirement testable?
– …
77
– Product Refinement:
e.g. If you are creating Internet Explorer 8 then you will make heavy
use of surveys and focus groups
•
•
•
•
What features of IE7 do you use – check multiple items in list.
What problems do you experience with IE7?
Give rankings to the following features …
Suggest other features
– Projects that involve new systems will rely more on individual
interviews and facilitated meetings
• Facilitated meetings are likely to represent a better use of your time
• You will need to re-interview the same individuals or group as you
move from exploring the current business context through to
developing detailed requirements for the new system
• Approaches like direct observation of people at work may be useful
occasionally, but more likely it will be viewed as intrusive and disruptive
78
13
27/05/2014
Do requirements
Do requirements
Facilitated meeting
Adapted from Pressman’s suggestion
list for facilitated meeting
• The style is similar to the “review”
meetings that we discussed ages ago
under testing.
The same issues:
• Meeting is conducted at a neutral site and attended
by both software engineers and customers;
• Rules for preparation and participation are
established;
• An agenda is prepared that is formal enough to cover
all important points but informal enough to encourage
the free flow of ideas;
• A facilitator controls the meeting;
• A “definition” mechanism is used (often the best is
one of those “electronic” white-boards that can make
copies);
• The goal is to identify the problem, propose elements
of the solution, negotiate different approaches and
specify a preliminary set of solution requirements.
– “Neutral” facilitator
– Planned meeting with timetable
– Scribe recording meeting
79
Do requirements
80
Do requirements
Several meetings are likely!
Several meetings are likely!!
1.
3.
The problem domain:
•
•
Activity diagrams (workflows) for what currently is done
Speculative activity diagrams for what these workflows might be
like when the new system has been deployed
Glossary
Some of the constraints – “must use IIS and .NET because that
is what our other systems use”
A first sketch of (process) architecture and deployment of system
•
•
•
2.
The activities! Time to clarify functionality from perspective of
problem domain and users.
•
•
Who are the “actors”?
What do they want to do?
•
•
•
•
4.
•
Check those requirements, conflicts? Inter-dependencies
Remember that “Vision” thing – you should have enough
information to produce the vision (your system is going to satisfy
these needs)
Use case overviews become detailed use cases
•
Needs
•
convert needs (domain view) to features (software view); try to
avoid commitment to particular implementation at this stage
Possibly refine the “future system” Activity Diagrams
Review features and activity diagrams with the stakeholders –
corrections!
From features move to functional requirements as use case
overviews
Offline
•
•
Offline (not at meeting):
•
Features become requirements
•
•
At this point, you might augment facilitated meeting by interviews
with stakeholders who can represent the actors involved in
specific use cases
Use case scenarios – get the typical behavior first but remember
to ask about exceptional cases
Document those use cases using detailed templates
81
Do requirements
82
Do requirements
Several meetings are likely!!
Several meetings are likely!!
5.
7.
Storyboarding and interface prototypes
•
Storyboarding of user interaction (going over possible
working of use case with person who supplied it):
•
•
6.
Acts as a review process for the use cases – you are saying
“this is how you will do it”, an excellent opportunity for the
user to say “That is NOT what I want to do!”
Often results in additional information about system that had
never been volunteered before (“Its obvious”, “I thought you
knew that”, “I forgot to mention … “)
•
Architectural and non-functional requirements
•
“draw these out”
•
83
Reviews
•
•
•
Vision
Use cases, their attributes like priorities
…
The sequence of meetings given here is just a
suggestion – you adapt it according to the needs of
your project.
Step-4, use case overviews to use cases, generally
involves many individual interviews.
84
14
27/05/2014
Do requirements
Do requirements
Use case template – hence
questions
Questioning for use cases
1. Characteristic information
• What questions should you be asking
when trying to get a stakeholder to
elucidate a “use case”?
–
Goal in context
•
–
•
–
• Well, just look at your use case
template
What are we trying to achieve in this case?
Scope
Where and when does it get used?
Preconditions
•
–
Does other stuff have to get done first?
Failed end condition
•
–
Suppose it doesn’t work out, what then
Primary actor
•
–
Who uses it?
Trigger
•
How does one start?
85
Do requirements
Do requirements
Use case template – hence
questions
Use case template – hence
questions
4.
2. Main success scenario
–
Related Information
–
Please explain the typical successful workflow
Priority
•
–
3. Extensions
–
86
•
–
Are there special cases that require additional
work?
What priority would you accord this feature?
Performance Target
How quickly would you expect to accomplish this task using the
system?
Frequency
•
–
How often will it be used?
Channel to primary actor
•
–
What style of user interface / control will be used?
Secondary actors
•
–
Will other people use it apart from the main users?
Channel to secondary actor
•
How will they access it?
87
Do requirements
More suggestions for questions –
K.E. Wiegers
Reluctant stakeholders
•
88
“… in my experience, end-users usually do not think that building
IT systems is exciting. They know they need a new IT system
and play along with the software engineers as it's being
developed, but they are less enthused about the prospect of
conducting requirements workshops and design review
sessions.”
• You will have to take the active role in these
meetings, driving progress through directed
questioning
• Getting the business requirements –
–
–
–
–
–
What business problem are you trying to solve?
What would a successful solution do for you?
What's it worth?
Who might influence the project?
What business activities and events be included?
Which should be excluded?
– Could the new system have adverse
consequences for some stakeholders?
Paraphrased from Wiegers' "More about software requirements"
Quote is from Krebs – part of his argument for using “storyboards” as a
technique for enthusing stakeholders
89
90
15
27/05/2014
Do requirements
More suggestions for questions –
K.E. Wiegers
Facilitated Application Specification
Techniques
• Getting ideas for use cases –
–
–
–
–
–
–
–
–
–
Why would you and your colleagues use the system?
What goals do you have where this system would help?
What problems might it solve for you?
Are specific aspects more critical?
Are there constraints to which product must conform?
How would your workflow change?
Is there any aspect of system that excites you?
How would you judge whether the system is successful?
…
91
Do requirements
92
Do requirements
Questionnaires
Questions to help get started
• You don’t go into these things cold¶ - you
have standard questionnaires that you can
use as a guide.
• Identify goals, benefits, constraints:
– Who wants the system?
– Who will use the system? Willingly?
– What is the potential economic benefit from a
successful solution?
– Is a (pre-existing) solution available from another
source?
– When do you need it by?
– Can you prioritize your needs?
– What are your time/cost/manpower constraints?
• For the most part, such guides are generic –
really just “good interviewing technique” and
“things to remember while interviewing”
• (Following lists are based largely on those in
Pressman’s Software Engineering text, but all such
lists date back to Gause & Weinberg ~ 1989)
¶ Of course not. Actually, you won’t be going into any of these things for a long time.
When you first do, you will find out that you have no name – being introduced simply
as ‘one of the team’. It will be five to ten years before you are a requirements engineer!
93
Do requirements
94
Do requirements
Questions to help characterize
overall problem and solutions
Gause+Weinberg “calibration and
tracking questions”
• What would be a “good” solution to the
problem?
• What problems is the system trying to
address?
• In what environment will the system be used?
• Are there any special performance issues?
• Are there other special constraints?
• What is (un)likely to change?
• Future evolution?
• What needs to be flexible (vs. quick & dirty) ?
95
• Are you the right person to answer these
questions?
• Are your answers “official”?
– If not, whose are?
• Are these questions relevant to the problem
as you see it?
• Is this the correct level of detail?
• Is there anyone else I should talk to?
• Is there anything else I should be asking you?
• Have you told me everything you know about
the problem?
96
16
27/05/2014
Do requirements
Do requirements
“Are you opposed to this system?”
Un-askable questions (ask indirectly)
• Apocryphal but not atypical story:
• I thought this list of questions rather “cute”:
–
–
–
–
–
–
–
– Jim thinks:
“This new ANSWER information system – it is really Dave’s baby.
It kind of serves my department, but it is really more focussed on
the needs of his department.
A couple of our ideas didn’t get in.
If it works, Dave will look good.
I am competing with Dave for promotion.
If it isn’t successful, Dave won’t look good.
Really Dave’s system isn’t what we need.
Several of my people said it wasn’t ideal.
Pete and Joe identified some issues; Kathy opposed it entirely –
but then she opposes any change.
I’ve got to appoint someone in my department to take responsibility
for our side of the project.
Uhm.
Who?
Kathy doesn’t have any major projects just at the moment.”
– Memo: To: Ms K Styles, Re: ANSWER system: Subject:
Appointment as ANSWER coordinator for this department
Are you opposed to the system?
Are you trying to obstruct/delay the system?
Are you trying to create a more important role for yourself?
Do you feel threatened by the proposed system?
Are you trying to protect your job?
Is your job threatened by the new system?
Is anyone else’s?
• I guess the analyst who proposed these metaquestions had met Ms. Kathy Styles and her boss
Jim (my example from the Software Engineering overview
lecture)
• But one thing I don’t get is how you ‘indirectly’ ask
“Are you trying to obstruct or delay the system?”
97
Do requirements
98
Do requirements
Generic questions … well ok, but
What are our first real hard
targets?
• Those generic lists obviously help set context
and provide some general guide to running
interviews.
• Of course, most of your questions will be:
• Well, there is that Vision thing – if we don’t have a
good vision, the project gets canned.
• But the real target is that “baselined executable
architecture”
– Initially, about the problem domain and current
overall workflows
– Subsequently, about specific needs and desired
solutions
• Conventional questioning styles don’t typically focus
sufficiently on architecture.
• With a little prompting, your stakeholders will
be able to respond to your questions and will
characterize the system functionality.
• But we are missing something …
Your product vision is accepted – and then you find
yourself in “Elaboration” with no idea of what you
really have to build,
you have no architectural vision.
99
Do requirements
100
Do requirements
“Drawing out” architectural
requirements
“Supplementary requirements”
• Peter Eeles’s paper in the IBM/Rational
series makes a number of points relating to
architectural issues.
– He provides a more elaborate review of the
usability, reliability, performance, supportability
type of non-functional requirement that got a brief
mention in McEwan’s overview
– He provides a list of what he calls “analysis
mechanisms” – really these are aspects of a
system that are commonly needed but which don’t
relate to any specific functional requirement
101
• The requirements relating to the “-ilities” or to topics under
“analysis mechanisms” are system wide – unrelated to “use
cases”
• So they end up in the “supplementary requirements”.
• But often are more important than the use cases with respect to
architectural design.
102
17
27/05/2014
Do requirements
Do requirements
FURPS+
FURPS+: Functionality
• Classification scheme for requirements (originally from
• Not simply the functions from the problem
domain
• There are a large number of functions that
are architecturally significant but which are
system wide in nature
Grady at Hewlett Packard)
• FURPS
–
–
–
–
–
Functionality
Usability
Reliability
Performance
Supportability
–
–
–
–
–
• +
–
–
–
–
Design constraints
Implementation constraints
Interface constraints
Physical constraints
Logging?
Transactions?
Data persistence?
Security?
…
103
Do requirements
104
Do requirements
FURPS+ : usability, reliability,
performance, supportability
FURPS+ : constraints
• Suggestions of questions that might be asked
to help elucidate this information
• The + constraints are to be considered along with
other requirements
– Design constraints
– Usability:
• Limits on the design; e.g. requiring a relational database
stipulates the approach that we take in developing the system.
• Accessibility: Are there any special requirements that
relate to the ease with which the system can be
exercised?
• Aesthetics: Are there any special requirements regarding
the “look and feel” of the system?
• Consistency: Are there any special requirements
regarding the consistency of the user interface, both
within the system and with other systems?
– Implementation constraints
• Limits on coding or construction; e.g. use C#, use IIS
– Interface constraints
• A requirement to interact with an external item; often describing
communication protocols that must be supported
– Physical constraints
• Constraints on the physical hardware used for the system
(requirements for power consumption, cooling etc)
– (Similar example questions for other “-ilitiies”)
105
Do requirements
106
Do requirements
Once again, example questions
Eeles’ “analysis mechanisms”
• Implementation constraints:
•
•
•
•
•
•
•
•
•
•
•
•
•
– Third party components?
• Are there any constraints (including costs) on the use of
third-party components in the system?
• How important is it for the system to be vendor
independent in terms of third-party components it uses?
• Are there any approved relevant alliances with third-party
vendors?
– Implementation languages?
• …
– Standards compliance?
• …
107
Auditing
Communication
Debugging
Error management
Event management
File management
Graphics
Information exchange
Licensing
Localization
Mail
Mega-data
Memory management
•
•
•
•
•
•
•
•
•
•
•
•
•
Meta-data
Online help
Persistence
Printing
Process management
Reporting
Resource management
Scheduling
Security
Systems management
Time
Transaction Management
Workflow
108
18
27/05/2014
Do requirements
Do requirements
Analysis/Design/Implementation
Eeles’ questionnaire
• Each of these “mechanisms” maps into
some design choices and eventual
implementation.
• Example questions are provided to help elicit these
system wide supplementary requirements:
Auditing
Functionality
Supportability
Design requirement
Licensing
Functionality
Design requirement
109
What do we want? Everything.
When do we want it? Now.
Transaction
management
Functionality
Design requirement
Is audit capability required?
What level of auditing is needed?
Are there any constraints on the mechanism used to
provide audit capability?
Will the system, or parts of the system, be licensed?
Are there any constraints on the mechanism used to
provide licensing capability?
Will transactional capability be required?
Are there any constraints on the mechanism used to
provide transactional capability?
110
Costs
• You wont be able to indicate an exact cost.
• Eeles’ lists give commentaries on how inclusion of a feature
might affect project – these can be used to start discussion with
stakeholder to determine whether the benefit of the feature is
likely to be worth the cost.
• Nothing free in this world.
• If you ask “Do you want security?” the
answer is Yes.
• If you ask “Do you want on-line help?”
the answer is Yes.
Authentication
Functionality
Design
requirement
• But each feature has costs for
development.
Is there any requirement for
authentication?
Are there any constraints on the
mechanism used to provide
authentication capability?
The greater the sophistication of
the authentication mechanism,
the longer the time to market, and
the greater the longterm
maintenance cost
He must have got bored, almost always it just says “the longer the time to market”
111
112
Do requirements
Krebs: Storyboards
Requirements
• Krebs’ paper in the Rational/IBM series discusses the
use of storyboarding in the requirements elicitation
process.
• Essential argument is that combination of
storyboarding and use case elaboration gives
stakeholders a much better understanding of a
system under development and often will help flush
out forgotten requirements.
113
114
19
27/05/2014
Doing requirements …
Another challenge for the techies
• “The major problems of our work are not
so much technological as sociological in
nature”
• “Software development is intrinsically a
human activity. People are the most
important factor in the success of your
project”
• Computer science students do for the most
part fit the stereotype
– “nerdy”
– “poor communication skills”
– “poor interpersonal skills”
• (OK, you are different – but that is just you.
You know this is true of all the others!)
• So CS students will have considerable
difficulty when interacting with stakeholders to
get requirements.
115
116
No worries
Well some worries maybe
• Don’t worry
• You won’t be “doing requirements” for a
long time (apart from pretend exercises
for various university projects)
• By the time you’ve risen sufficiently to
get on the requirements team you will
be less nerdy, and more
communicative.
Requirements for CSCI321, CSCI222, CSCI311, …
117
You have to create
“requirements documents”
118
Your documents
• Your groups will have to create
“Requirements Documents” for
• Use simple templates for functional and
non-functional requirements
• Functional requirements template
– CSCI222 “Inception & Elaboration”
assignment
– CSCI311 & CSCI318 assignments
– CSCI321 project
– Well what did SWEBOK want
• A unique identifier
• A priority rating
– Possibly also a suggestion as to iteration phase when it will be implemented
– but this is getting out of requirements and into process; it’s best just to
have priority.
• A status value
• And, of course, a description of a property which must be
exhibited in order to solve some problem in the real
world!
119
120
20
27/05/2014
Functional requirement
template?
Identifier
Priority
Template example
• Examples for a kind of simplified subject
management package for a college:
Status
– Any WW user can
Statement
• See subjects on offer in current session
• See details of chosen subject
– Lecturer can
• Edit assessment mechanism for a subject for which he/she is
responsible
• Add students to a subject for which he/she is responsible
– Tutor and lecturer can
Status is only useful if have an active requirements document in some
electronic form that can be updated as progress made, and viewed by
management. (Of course, any such document must be versioned so can
see later changes to priorities or requirement statements.)
• Upload marks
• View marks
121
Template examples
View-1
Priority 1
122
Template examples
-
View-2
The system shall provide a WWW view of subjects on offer in the current
teaching session.
Priority 1
-
The system shall provide a WWW view of the content and objectives of
any chosen subject
123
Template examples
Controlled-access Priority 2
124
Template examples
-
View-3
The system shall permit staff members – lecturers and tutors – to login
to gain access to subject management options, and to subsequently
logout.
125
Priority 3
-
The system shall provide to logged in staff members a WWW view
of the content, objectives, and assessment mechanisms of
any chosen subject
126
21
27/05/2014
Template examples
View-4
Priority 3
Requirements & use cases
• Requirements in such tabular template forms
will map onto use cases
-
– Often it’s a 1-to-1 mapping
The system shall provide to logged in lecturers a WWW view
of the enrolled students in any chosen subject for which they have
teaching responsibility.
• Requirement “View-1” becomes “Use case 1 – viewing
subject list”
– Sometimes more involved
• When get to use cases, might decide that there is only “Use
case 2 – view subject details” but this has variant scenarios
for the View-2 and View-3 requirements (the assessments
appear if the user is a staff member)
– Sometimes more than one use case
• “Controlled access” requirement might appear as login and
logout use cases
127
128
Requirements & use cases
Requirements & use cases
• Requirements in such tabular template forms
will map onto use cases
• Have to maintain a matrix recording such
mappings requirement => use case(s).
• Isn’t it all a bit redundant?
– Will of course later create matrix representations showing
how use cases map onto implemented software artefacts
• Might want to rework these to show mapping from requirements
to software artefacts;
might be needed in progress reviews
129
– These requirements and then the use cases
• It’s kind of the same information presented for
different audiences
– Requirements template style – for commissioning
stakeholder (senior executive level)
• A quick high level overview and summary
– Use cases – for stakeholders more involved in
actual use of a system
• End users, testers, …
And of course, there is the real use case based on a detailed template to supplement
the “stickman” use case!
130
Non functional requirements
• Just a list of identifiers and requirement
statements.
• Traceability into implementation is often harder
– “Implemented in C++”
• Easy to check!
– “Must return a response within 2 seconds for all requests in
functional requirements f6, f7, f9, f13, f17, … while serving 200
concurrent clients”
• Much harder to identify in implementation
– Could influence architecture choices – e.g. employment of memcache servers for frequently
occurring WWW use cases;
– Could impact on data persistence design – e.g. addition of indexes to speed important queries;
– Could affect aspects of coding – e.g. complex, indexed data structures rather than simple lists.
131
22