3. What is a requirement?
A statement of a system service or constraint
It may range from a high-level abstract statement
of a service or of a system constraint to a detailed
mathematical functional specification.
Requirements may serve a dual function
May be the basis for a bid for a contract -
therefore must be open to interpretation;
May be the basis for the contract itself -
therefore must be defined in detail;
Both these statements may be called
requirements.
4. What is 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.
5. What is Process?
• A process is an organised set of activities
which transforms inputs to outputs
• Process descriptions encapsulate
knowledge and allow it to be reused
• Examples of process descriptions
– Cookery book
– Procedures manual for a bank
– Quality manual for software development
6. What is a requirements engineering
process?
• The structured set of activities involved in developing
system requirements
• Process activities include requirements elicitation,
requirements analysis and negotiation, requirements
specification, requirements validation and
requirement management
• A complete process description should include
– what activities are carried out,
– the structuring or scheduling of these activities,
– who is responsible for each activity,
– the inputs and outputs to/ from the activity and
– the tools used to support requirements engineering
7. Is there an ideal requirements engineering
process?
• No - processes must be tailored to organisational needs
• Each organization tailored the process according to the
type of systems it develops, its organizational culture
and the level of experience and ability of the people
involved in requirements engineering.
• To define a good requirements engineering process,
organizations need to involve the people who are
actually part of requirement engineering.
8. How much does requirements engineering
cost?
• About 15% of system development costs
• The requirement engineering cost depends on
the type and size of the system being
developed
• In some cases, the system requirements are not
developed in detail; in others a formal
specification may be produced.
9. Relative cost to correct a requirement defect
in different phases
10. What happens when the requirements are
wrong?
• The system may be delivered late and costs
more than originally expected
• The customer and end-user are not satisfied
with the system. The may not use its facilities
and may even decide to scrap it altogether
• The system may be unreliable in use, with
regular system errors and crashes disrupting
normal operation
• If the system continue in use, the cost of
maintaining and evolving the system are
usually very high.
11. What is a requirements document?
• The formal statement of the system
requirements for customer, end user and
software developers.
• Depending on the organization, the
requirement document may have different
names such as
– Functional specification
– The requirements definition
– The software requirements specification (SRS)
12. What is the relationship between
requirements and design?
• Requirements are mostly concerned with the
problem to be solved; design is concerned with
the solution to the problem
• That is requirements engineering is about what
has to be done; design is about how it should be
done
• They should, ideally, be separate processes but
in practice this is impossible.
• In reality, requirements engineering and design
are interlaced activities.
13. Reasons why requirement engineering and
design are interlaced activities?
• Systems are always installed in some environment, and there are
always other systems in the environment. These other systems
constraints the design of the system.
• For large systems, some architecture design is necessary to
identify sub systems are their relationships. Requirements for
these subsystems may then be specified.
• For reasons of budget, schedule or quality, an organization may
wish to reuse some or all of existing software systems in the
implementation of the new system. This constraints both the
system requirements and the design.
• If a system has to be approved by an external regulator (e.g.
aircraft), it may be necessary to use a standard ‘certified design’
which has been tested in the other systems.
14. What are system stakeholders?
• Anyone affected in some way by the
system and who have a direct or indirect
influence on the system requirements
• The stakeholders include
– end-user of the system,
– customer of the system,
– managers and others involved in the
organizational processes influenced by the
system,
– engineers responsible for the system
development and maintenance
15. Who is the Customer?
•A customer is an individual or organization who
derives either direct or indirect benefit from a
product.
•Software customers include those project
stakeholders who request, pay for, select, specify,
use, or receive the output generated by a software
product.
•They provide the high-level concept for the product
and the business rationale for launching it,
establishing the Product Vision and Product Scope
16. What is Business Requirement
• Business requirements describe the business objectives that
the customer, company, or other stakeholders want to
achieve.
• Business requirements establish a guiding framework for the
rest of the project.
• All other product features and requirements ought to align
with satisfying the business requirements.
• Business opportunities, business objectives, success metrics,
and a vision statement make up the business requirements.
• However, business requirements don't provide sufficient
detail to tell developers what to build.
17. User Requirements
•User requirements should come from people
who will actually use the product, directly or
indirectly.
•These users (often called end users) therefore
constitute another kind of customer.
•Users can describe the tasks they need to
perform with the product and the quality
characteristics they expect the product to
exhibit.
18. System requirements
•System requirements
•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.
20. Functional requirements and non Functional
Requirements
• Functional requirements
• specify the behaviors the product will exhibit under specific
conditions.
• They describe what the developers must implement to enable users
to accomplish their tasks (user requirements), thereby satisfying the
business requirements.
• Functional requirements often are written in the form of the
traditional “shall” statements:
• “The Passenger shall be able to print boarding passes for all flight
segments for which he has checked in”
• Nonfunctional requirement
• A description of a property or characteristic that a system must
exhibit or a constraint that it must respect.
• Constraint is a restriction that is imposed on the choices available to
the developer for the design and construction of a product.
21. Feature
•A feature consists of one or more logically related
system capabilities that provide value to a user and
are described by a set of functional requirements.
•Web browser bookmarks, spelling checkers,
automatic virus signature updating in an anti-
malware product are examples of features
•A feature can encompass multiple user
requirements, each of which implies that certain
functional requirements must be implemented to
allow the user to perform the task described by
each user requirement.
23. Users of requirements documents
•System customers
• specify the requirements and read them to check they
meet their needs
•Project managers
• Use the requirements document to plan a bid for system
and to plan the system development process
•System engineers
• Use the requirements to understand the system being
developed
•System test engineers
• Use the requirements to develop validation tests for the
system
•System maintenance engineers
• Use the requirements to help understand the system
24. Sign-Off
•Reaching agreement on the requirements for the
product to be built is at the core of the customer-
developer partnership
•Many organizations use the concept of signing off
on the requirements document as the mark of
customer approval of those requirements
•Sign-off ritual is the concept of establishing a
baseline of the requirements agreement
25. Factors influencing requirements
• The personal goals of individuals within an organisation
• Each group of stakeholders have different goals. They will try to
influence the requirements so that their goals are met, without
necessarily taking the goals of the other stakeholders into account
• Personality and status of stakeholders
• If the end user has managerial support then their requirements
will probably be accepted
• If the end user has an aggressive personality , the engineers may
agree to accept their requirements simply to get rid of them
• The degree of political influence of stakeholders within an
organisation
• People try to influence system requirements, so that they can
maintain or increase their own political influence in the
organization.
• If a budget information system is planning in a university, both
administration and academic departments are likely to propose
requirements which give them more power
26. Requirements risks
• Insufficient User Involvement
• Customers often don't understand why it is so essential to work hard on
gathering requirements and assuring their quality
• Developers might not emphasize user involvement, either because
working with users isn't as much fun as writing code or because they
think they already know what the users need
• In some cases, it's difficult to gain access to people who will actually use
the product, and user surrogates don't always understand what users
really need
• Insufficient user involvement leads to late-breaking requirements that
delay project completion
27. Requirements risks
• Creeping User Requirements
• As requirements evolve and grow during development, projects often
exceed their planned schedules and budgets
• To manage scope creep, begin with a clear statement of the project's
business objectives, strategic vision, scope, limitations, success
criteria, and expected product usage.
• Evaluate all proposed new features or requirements changes against
this reference framework
28. Requirements risks
•Ambiguous Requirements
• a reader can interpret a requirement statement in several ways
• Ambiguity also results from imprecise and insufficiently detailed
requirements that force developers to fill in the blanks.
• Ambiguous requirements result in wasted time when developers
implement a solution for the wrong problem.
• Testers who expect the product to behave differently from what
the developers intended waste time resolving the differences.
29. Requirements risks
•Minimal Specification
• Sometimes marketing staff or managers are tempted to
create a limited specification
• They expect the developers to expand the spec while the
project progresses
• This might work for a tightly integrated team that's building
a small system
• In most cases, though, it frustrates the developers and
disappoints the customers
