Transcript lecture_4 - MS(Software Engineering

REQUIREMENTS ENGINEERING
PROCESS
Lecture 4
Requirements
• A requirement is defined as:
– A condition or capability needed by a user to solve a
problem or achieve an objective;
• A condition or a capability that must be met or possessed by a
system … to satisfy a contract, standard, specification, or other
formally imposed document …” IEEE 830-1993
• The primary measure of success of a software
system is the degree to which it meets the purpose
for which it was intended.
– Broadly speaking, software systems requirements
engineering (RE) is the process of discovering that
purpose, by identifying stakeholders and their needs, and
documenting these in a form that is amenable to analysis,
communication, and subsequent implementation.
» Bashar Nuseibeh
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
2
Requirements Engineering
• The process of establishing the services that the customer
requires from a system and the constraints under which it
operates and is developed.
– The requirements themselves are the descriptions of the system
services and constraints that are generated during the requirements
engineering process.
• Requirements Type:
– User requirements
• Statements in natural language plus diagrams of the services the system
provides and its operational constraints.
• Written for customers.
– System requirements
• A structured document setting out detailed descriptions of the system’s
functions, services and operational constraints.
• Defines what should be implemented so may be part of a contract
between client and contractor.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
3
Challenges to Requirements
• There are a number of inherent difficulties in RE process:
– Stakeholders may be numerous and distributed.
– Stakholder’s goals may vary and conflicting
• Depending on their perspectives of the environment in which they work
and the tasks they wish to accomplish.
– Stakeholder’s goals may not be explicit or may be difficult to
articulate:
• satisfaction of these goals may be constrained by a variety of factors
outside their control.
– Limitation of natural language
• Ambiguity, consistency, understandability
–
–
–
–
Writing vs reading
Verity of methods
Controlling/ managing/ tracing changes
validation
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
4
Challenges to Requirements
• So Many “Requirements”…
– A goal is an objective or concern used to discover and evaluate
functional and non-functional requirements.
• A goal is not yet a requirement…
– A functional requirement is a requirement defining functions of the
system under development
• Describes what the system should do
– A non-functional requirement is a requirement characterizing a system
property such as expected performance, robustness, usability,
maintainability, etc.
• Constraints that must be adhered to during development
– A user requirement is a desired goal or function that a user and other
stakeholders expect the system to achieve
• Does not become necessarily a system requirement
– A domain requirement is a requirement derived from the application
domain
• Can be functional or non-functional
– Product Requirement
– Process requirement
– Security Requirements
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
5
Challenges to Requirements
• Elicitation Risks and Challenges
– Problems of scope
• System boundaries inadequately defined or defined too soon
• Unnecessary technical details
– Problems of understanding
• Stakeholder not sure of what is needed
• Stakeholder has trouble communicating needs
• Stakeholder does not understand capabilities and limitation of computing
environment
• Stakeholder does not have full understanding of domain
• Stakeholders state conflicting requirements
– Problems of volatility
• Stakeholders will not commit to a set of written requirements
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
6
Challenges to Requirements
• Elicitation Risks and Challenges
– Other typical issues
•
•
•
•
•
Experts seldom available
Finding an adequate level of precision/detail
Common vocabulary often missing
Sometimes hidden
Sometimes too obvious, implicit, ordinary…
– Participants often lack motivation and resist to
change
• We need much efforts and discussion to come up with a common
agreement and understanding
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
7
Software Requirement- SWEBOK
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
8
Requirements Engineering
• “Requirements engineering is the branch of software
engineering concerned with the “REAL-WORLD GOALS” for,
functions of, and constraints on software systems. It is also
concerned with the relationship of these factors to “PRECISE
SPECIFICATIONS” of software behavior, and to their
EVOLUTION OVER TIME AND ACROSS SOFTWARE
FAMILIES.”
– Real world Goals: Motivate the development of a software
system.
• Represent the ‘why’ and ‘what’ of a system.
– Precise Specification: Provide the basis for:
•
•
•
•
Analyzing requirements,
Validating (what stakeholders want),
Defining what designers have to build, and
Verifying that they have done so correctly upon delivery
– Evolution over Time: Emphasizing the reality of a changing world
and the need to reuse partial specifications,
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
9
Software requirements engineering
• Process of determining what is to be produced in a
software system
• An important aspect of any software project, and is
a general term used to encompass all the activities
related to requirements.
– The four specific steps in software requirements
engineering are:
•
•
•
•
Requirements Elicitation
Requirements Analysis
Requirements Specification
Requirements Validation
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
Seems to be separate tasks but
these four processes cannot be
strictly separated and performed
sequentially and repeatedly
10
RE Activities
• Requirements elicitation
– Requirements discovered through consultation with
stakeholders
• Requirements analysis and negotiation
– Requirements are analyzed and conflicts resolved
through negotiation
• Requirements specification
– A precise requirements document is produced
• Requirements validation
– The requirements document is checked for consistency
and completeness
• Requirements management
Acknowledgement to the
work of Karl Wiegers,
Software Requirements
– Needs and contexts evolve, and so do requirements!
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
11
Why Focus on Requirements
•NIST (National Institute of Standards and
Distribution of
Technology's)
Distribution of Effort to Fix Defects
Defects
–70 % of the defects are introduced in the specification
phase
Code
–30 % are introduced
later in the technical solution
process.
Code
Other
Design
1%
Requirements
7%
4%
Requirements
Other
–Only56%
5 % of the specification
inadequacies
are corrected13%in
82%
10%
the specification phase
–95 % are detected later in the project or after delivery
where the cost for correction in average is 22 times higher
compared to a correction directly in the specification effort.
• The NIST report concludes
that extensive testing is
Design
27%
essential, however testing
detects the dominating
•(Martin & Leffinwell)
specification errors late in the process.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
12
Standish CHAOS Report -2010
– “This year’s results show a marked decrease in project
success rates, with 32% of all projects succeeding which
are delivered on time, on budget, with required features
and functions”
– Jim Johnson, chairman of The Standish Group says:
• “44% were challenged which are late, over budget, and/or with
less than the required features and functions and 24% failed
which are cancelled prior to completion or delivered and never
used.”
– Five of the eight main factors for project failure deal with
requirements:
•
•
•
•
•
incomplete requirements,
low customer involvement,
unrealistic expectations,
changes in the requirements,
and useless requirements.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
13
RE Process and Related Activities
Why?
Identify Business Needs and Goals
What?
Derive User & Functional Requirements
How?
Design Solutions
Who?
•
When?
If-Then
Does It?
Where?
Time
TIME
Whether viewed at the systems level or the software level, RE
Project Management Process
is a multi-disciplinary, human-centred process.
– Risk
The tools
and techniques
used in RE draw upon a variety of
Management
Process
disciplines, and the requirements engineer may be expected to
master skills from a number of different disciplines.
Quality
Management
Process
• RE must
span the gap between
the informal world of stakeholder
needs, and the formal world of software behaviour, the key question
over the use&ofConfiguration
formal methods is Management
not whether to formalise,
but when
Component
Process
to formalise
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
14
Why
• “If you don’t get the requirements right, it doesn’t matter how
well you do anything else.” One can end up doing a perfect
job of building the wrong product.
» Karl Wiegers (2004)
• Issues that can have a negative impact
– Incomplete requirements:
• A software product that does not meet all of the customer and user’s
needs.
– Lack of user involvement:
• if practitioners miss a stakeholder group
– Requirements mix:
• changes in the requirements after initially agreement, missing, poorly
written or ambiguous requirements
– Wasted resources:
• Requirements errors results in 70-85 percent of the rework
– Gold plating:
• Developer adds functionality that was not in the requirements
specification
– Inaccurate estimates:
• Requirement defines the scope, scope help is schedule and cost
estimation
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
15
“What”- Part of the Requirements
• Requirements must be determined and agreed to by the
Why the Software is being developed
customers, users, and suppliers of a software product before
the software can be built.
• The requirements define the “what” of a software product:
– What the software must do to add value for its stakeholders.
• These functional requirements define the capabilities of the software
product.
– What the software must be to add value for its stakeholders.
• These nonfunctional requirements define the characteristics, properties,
or qualities that the software product must possess.
• They define how well the product performs its functions.
– What limitations there are on the choices that developers have when
implementing the software.
• The external interface definitions and other constraints define these
limitations.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
16
Who
• Stakeholders  who affect or are affected by the
software product and therefore have some level of
influence over the requirements for that software
product.
– The RE process consider all of the various stakeholder’s
interest in context with one another.
– Stakeholders
• Acquirers
– Purchasers & end users
• Suppliers
– Organization & Developers (requirement Analyst, designer,
Developers, Testers & technical writer
• Others
– Legal or contract management, Government or regulator agencies &
Society at large
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
17
Who
• The first step in identifying the stakeholders is to
make sure that one considers all of the potential
stakeholders.
• The following checklist can help in identifying
potential stakeholders:
– What types of people will use the software product?
– What business activities are supported by the software
product and who performs, or manages those activities?
– Whose job will be impacted by the introduction of the new
software product?
– Who will receive the reports, outputs, or other information
from the software product?
– Who will pay for the software product?
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
18
Software Requirement- SWEBOK
•
Requirements Process
– Process Actors
• Stakeholders
•
•
Process Support and Management
– make the link between the process activities and the
issues of cost, human resources, training, and tools.
Requirements Sources
– Goals.
• (sometimes called ‘business concern’ or ‘critical success factor’)
refers to the overall, high-level objectives of the software.
–
–
–
–
–
–
Domain knowledge.
Stakeholders
The operational environment.
The organizational environment.
Similar System
Documents / regulation / SOPs
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
19
How
• Software requirements engineering is a disciplined, processoriented approach to the definition, documentation, and
maintenance of software requirements throughout the
software development life cycle.
– software requirements engineering is made up of two major
processes: requirements development and requirements
management.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
20
How part of Requirements
•
Requirements Engineering: A Roadmap, Bashar Nuseibeh
– The context in which RE takes place is usually human activity system
and the problem owner are people.
– Techniques for eliciting and modeling, drawn on cognitive and social
sciences:
• Cognitive Psychology
– Provides an understanding of the difficulties people may have in describing
their needs
» domain experts often have large amounts of knowledge their answers to
questions posed by requirements analysts may not match their
behaviour.
• Anthropology
– Provides a methodological approach to observing human activities that helps
to develop a richer understanding
• Sociology
– Provides an understanding of the political and cultural changes caused by
computerization.
• Linguistics
– To avoid ambiguity and to improve understandability.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
21
Eliciting Requirements
• Elicitation Techniques
– Traditional Techniques
• Questionnaires and Surveys
• Interviews
• Analysis of existing
documentation
– Group Elicitation
• Group brainstorming
sessions
• RAD (Rapid Application
Development)
• JAD (Joint Application
Design)
• Requirements to Elicit
– Boundaries
• Identify the high level boundaries of
the system
• Stakeholders and Use Cases
depend on boundaries
– Goals
• Denote the OBJECTIVES a system
must meet.
• Eliciting High level goals early in
development
– High level goals (business goals) 
refined into lower level goals
(technical goals)  eventually
operationalised in a system
– Prototyping
• Where there is great deal of
uncertainty
• Early feedback from
stakeholders is needed
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
– Tasks
• When it is difficult to articulate user
requirements
– Observe, case studies, scenarios
22
Sources of Requirements
• Various stakeholders
– Clients, customers, users (past and future), managers,
domain experts, developers, marketing and QA people,
lawyers, auditors, anyone who can bring added value!
• Pre-existing systems
– Not necessarily software systems
•
•
•
•
Pre-existing documentation
Competing systems
Documentation about interfacing systems
Standards, policies, collective agreements,
legislation
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
23
Comparison of some techniques
Technique
Good for
Kind of data
Plus
Minus
Answering specific
questions
Quantitative and
qualitative data
Can reach many
people with low
resource
The design is
crucial. Response
rate may be low.
Responses may not
be what you want
Exploring issues
Some quantitative
but mostly
qualitative data
Interviewer can
guide interviewee.
Encourages contact
between developers
and users
Time consuming.
Artificial
environment may
intimidate
interviewee
Collecting multiple
viewpoints
Some quantitative
but mostly
qualitative data
Highlights areas of
consensus and
conflict.
Encourages contact
between developers
and users
Possibility of
dominant
characters
Naturalistic
observation
Understanding
context of user
activity
Qualitative
Observing actual
work gives insight
that other
techniques cannot
give
Very time
consuming. Huge
amounts of data
Studying
documentation
Learning about
procedures,
regulations, and
standards
Quantitative
No time
commitment from
users required
Day-to-day work will
differ from
documented
procedures
Questionnaires
Interviews
Focus groups and
workshops
Preece,
Adv Software Engg, MSCS 19, by Asst Prof Acknowledgment:
Athar Mohsin, MCS-NUST
Rogers, and Sharp “Interaction Design: Beyond human-computer interaction”, p21424
Software Requirement- SWEBOK
• Product Requirements
– Requirements on software to be developed
• The software shall verify that a student meets all prerequisites
before he or she registers for a course
• Process Requirements
– A constraint on the development of the software
• The software shall be written in C#.
– Imposed directly by the development organization, their
customer, or a third party such as a safety regulator
• Functional Requirements
– Describe the functions that the software is to execute –
AKA Capabilities
• Non-Functional Requirements
– The ones that act to constrain the solution AKA Constraints
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
25
Software Requirement- SWEBOK
• Emergent Properties
– Requirements which cannot be addressed by a single
component, but which depend for their satisfaction on how
all the software components interoperate.
• Quantifiable Requirements
– To avoid vague and unverifiable requirements which
depend for their interpretation on subjective judgment
• The software shall be reliable’
• ‘The software shall be user-friendly’
• System Requirements
– An interacting combination of elements to accomplish a
defined objective.
• Software requirements are derived from system
requirements.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
26
Functional Requirements
– What inputs the system should accept
– What outputs the system should produce
– What data the system should store that other
systems might use
– What computations the system should perform
– The timing and synchronization of the above
– Examples:
• The user shall be able to search either all of the initial set of
databases or select a subset from it.
• The system shall provide appropriate viewers for the user to
read documents in the document store.
• A user shall be able to search the appointments lists for all
clinics.
• The system shall generate each day, for each clinic, a list of
patients who are expected to attend appointments that day.
• Each staff member using the system shall be uniquely
identified by his or her 8-digit employee number.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
27
Non-functional classifications
•
Product requirements
No n-functio nal
requir ements
–
Requirements which specify that the delivered product must
behave in a particular way
• e.g. execution speed, reliability, etc.
– The userP roduct
interface for LIBSYSOrganis
shall
be implemented as simple
ational
External HTML
without
frames
r equir
ements or Java appletsrequir ements
r equir ements
•
Organisational requirements
–
Requirements which are a consequence of organisational policies
and
procedures
Efficiency
Relia bility
P or ta bility
Inter oper a bility
Ethical
r equir em
ents
requir
ements implementation
requir ements requirements,
r equir ements etc.
• e.g. process
standards
used,
requir ements
– The system development process and deliverable documents shall
conform to the process and deliverables defined in organization’s mission
statement
•
External requirementsDeli very
Us a bility
–
r equir ements
requir ements
Implementa
tion
requir ements
Standar
ds
requir ements
Leg isla tiv e
requir ements
Requirements which arise from factors which are external to the
system and its development process
• e.g. interoperability requirements, legislative requirements, etc.
P er for mance
requir ements
– The
Space system shall not disclose any personal information
P ri vacy about customers
Safety
apart
ofrequir
the ements
r equir
ementsfrom their name and reference number to the
r equir operators
ements
system.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
28
Metrics for specifying nonfunctional
requirements
Property
Measure
Speed
Processed transactions/second
User/event response time/ Screen refresh time
Size
Mbytes
Number of ROM chips
Ease of use
Training time
Number of help frames
Reliability
Mean time to failure / Availability
Probability of unavailability
Rate of failure occurrence
Robustness
Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability
Percentage of target dependent statements
Number of target systems
Domain requirements
• The system’s operational domain imposes requirements on
the system.
– For example, a train control system has to take into account the
braking characteristics in different weather conditions.
• Domain requirements be new functional requirements,
constraints on existing requirements or define specific
computations.
• If domain requirements are not satisfied, the system may be
unworkable.
• Problems
– Understandability
• Requirements are expressed in the language of the application domain;
• This is often not understood by software engineers developing the system.
– Implicitness
• Domain specialists understand the area so well that they do not think of making
the domain requirements explicit.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
30
Requirements imprecision
• Problems arise when requirements are not precisely
stated.
– Ambiguous requirements may be interpreted in different
ways by developers and users.
• Consider the term ‘search’ in following requirement
– A user shall be able to search the appointments lists for
all clinics.
• User intention:
– search for a patient name across all appointments in all
clinics;
• Developer interpretation:
– search for a patient name in an individual clinic. User chooses
clinic then search.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
31
Requirements completeness and consistency
• In principle, requirements should be both complete
and consistent.
– Complete
• They should include descriptions of all facilities
required.
– Consistent
• There should be no conflicts or contradictions in the
descriptions of the system facilities.
• In practice, it is impossible to produce a complete
and consistent requirements document.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
32
The software requirements document
• The software requirements document is the official
statement of what is required of the system
developers.
– Should include both a definition of user requirements and
a specification of the system requirements.
– It is NOT a design document.
– As far as possible, it should set of WHAT the system
should do rather than HOW it should do it.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
33
Requirements specification
• The process of writing the user and system
requirements in a requirements document.
– User requirements have to be understandable by endusers and customers who do not have a technical
background.
– System requirements are more detailed requirements and
may include more technical information.
• The requirements may be part of a contract for the
system development
– It is therefore important that these are as complete as
possible.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
34
Ways of writing a system requirements
specification
Notation
Description
Natural language
The requirements are written using numbered sentences in natural language. Each
sentence should express one requirement.
Structured
language
natural The requirements are written in natural language on a standard form or template.
Each field provides information about an aspect of the requirement.
Design
description This approach uses a language like a programming language, but with more
languages
abstract features to specify the requirements by defining an operational model of the
system. This approach is now rarely used although it can be useful for interface
specifications.
Graphical notations
Graphical models, supplemented by text annotations, are used to define the
functional requirements for the system; UML use case and sequence diagrams are
commonly used.
Mathematical
specifications
These notations are based on mathematical concepts such as finite-state machines
or sets. Although these unambiguous specifications can reduce the ambiguity in a
requirements document, most customers don’t understand a formal specification.
They cannot check that it represents what they want and are reluctant to accept it as
a system contract
Structure of a Good Requirement
Defines a subject
Shall or should verb
“The system shall allow the Internet user to access
his current account balance in less than 5 seconds.”
Defines a positive end result
Performance criteria
•This requirement sentence identifies a specific
subject and end result that is wanted within a
specified time that is measurable.
– The challenge is to seek out the subject, end result,
and success measure in every requirement you
define!
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
36
Example of a Bad Requirement
Cannot write a requirement on the user
No identifier for the verb
“The Internet user quickly sees the balance of her
account on the laptop screen .”
Vague quality criterion
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
What versus how
37
Standard for Writing a Requirement
–Each requirement must first form a complete
sentence
• Not a bullet list of buzzwords
–Each requirement contains a subject and predicate
• Subject: a user type or the system under discussion
• Predicate: a condition, action, or intended result.
–Consistent use of the verb:
• “shall,” “will”, or “must” to show mandatory nature
• “should” or “may” to show optionality
• Usually, shall and should are used.
–A requirement contains a success criterion or
other measurable indication of the quality.
–A requirement describes what must be done,
rather than how.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
38
Writing errors to Avoid
•Never describe how the system is going to
achieve something (over-specification), always
describe what the system is supposed to do
–Refrain from designing the system
• Danger signs: using names of components, materials,
software objects, fields & records in the user or system
requirements
–Designing the system too early may possibly increase
system costs
–Do no mix different kinds of requirements (e.g.,
requirements for users, system, and how the system
should be designed, tested, or installed)
–Do not mix different requirements levels (e.g., the
system and subsystems)
• Danger signs: high level requirements mixed in with
database design, software terms, or very technical terms
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
39
Writing errors to Avoid
•“What versus how” test
The system shall use Microsoft Outlook to send an
email to the customer with the purchase confirmation.
X
The system shall inform the customer
that the purchase is confirmed.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
40
Writing errors to Avoid
•Never build in let-out or escape clauses
–Requirements with let-outs or escapes are dangerous
because of problems that arise in testing
–Danger signs: if, but, when, except, unless, although
• These terms may however be useful when the
description of a general case with exceptions is much
clearer and complete that an enumeration of specific
cases
•Avoid ambiguity
–Write as clearly and explicitly as possible
–Ambiguities can be caused by:
• The word or to create a compound requirement
• Poor definition (giving only examples or special cases)
• The words etc, …and so on (imprecise definition)
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
41
Writing errors to Avoid
•Do not use vague indefinable terms
–Many words used informally to indicate quality are too vague
to be verified
–Danger signs: user-friendly, highly versatile, flexible, to the
maximum extent, approximately, as much as possible,
minimal impact
X
The Easy Entry System shall be easy to use and require
a minimum of training except for the professional mode.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
42
Writing errors to Avoid
•Do not make multiple requirements
–Keep each requirement as a single sentence
–Conjunctions (words that join sentences together) are
danger signs: and, or, with, also
•Do not use
–Long sentences with arcane language
–References to unreachable documents
X
The Easy Entry Navigator module shall consist of order
entry and communications, order processing, result
processing, and reporting. The Order Entry module shall be
integrated with the Organization Intranet System and
results are stored in the group’s electronic customer record.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
43
Writing errors to Avoid
•Do not speculate
– There is no room for “wish lists” – general terms about things that
somebody probably wants
– Danger signs: vague subject type and generalization words such
as usually, generally, often, normally, typically
•Do not express suggestions or possibilities
– Suggestions that are not explicitly stated as requirements are
invariably ignored by developers
– Danger signs: may, might, should, ought, could, perhaps,
probably
•Avoid wishful thinking
– Wishful thinking means asking for the impossible (e.g., 100%
reliable, safe, handle all failures, fully upgradeable, run on all
platforms)
X
The Easy Entry System may be fully adaptable to all
situations and often require no reconfiguration by the user.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
44
Requirements problem example
• “LIBSYS will be configurable so that it will comply
with the requirements of international copyright
legislation. Minimally, this means that LIBSYS must
provide a form for the user to sign the Copyright
Declaration statement. It also means that LIBSYS
must keep track of Copyright Declaration
statements which have been signed/not-signed.
Under no circumstances must an order be sent to
the supplier if the copyright statement has not been
signed.”
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
Dig out the problems in this
requirement
45
Problems in example requirement
• Incompleteness
–
–
–
–
What international copyright legislation is relevant?
What happens if the copyright declaration is not signed?
If a signature is a digital signature, how is it assigned?
Recommendation:
• Define all copyright legislation as a separate requirement
• Reword requirement as “ copyright declaration must be signed
before order is complete
• Introduce a new requirement for signature assignment
• Ambiguity
– What does signing an electronic form mean? Is this a physical
signature or a digital signature?
• Define what is meant by “signature”
• Standards
– More than 1 requirement. Maintenance of copyright is one
requirement; issue of documents is another
• Split the requirements in two or three separate requirements
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
46
Acknowledgement
• SWEBOK Chapter 4
• Requirements Engineering: A Roadmap
– Bashar Nuseibeh
• Software Requirements Engineering: What, Why,
Who, When and How
– Linda westfall
• Chapter 4 Software Engineering 9th edition – Ian
Sommerville
• Requirements Engineering – Kotonya &
Sommerville
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST
47