INTRODUCTION TO REQUIREMENT ENGINEERING

WHAT IS A REQUIREMENT?

A need to be satisfied
IEEE Definition:
1. A condition or capability needed by a user to solve a problem or achieve an objective [User].
2. A condition or capability that must be met or possessed by a system or system component to satisfy a
contract, standard, specification or other formally imposed documents [System].
REQUIREMENTS

 User Requirements – Written for customers, often in natural language, no technical details
 System Requirements – Written for developers, detailed functional and non-functional requirements, clearly and
more rigorously specified
LIFE CYCLE OF A REQUIREMENT

Requirement: there is a need

Problem: Find a way to full fil the requirement
Solution: A specific way of satisfying the requirement/need
AGILE METHODS AND REQUIREMENTS

• Agile methods value “Responding to change over following a plan”.

• The requirements document is therefore always out of date.
• Agile methods usually use incremental requirements engineering and may express requirements as ‘user
stories’
• This is practical for business systems but problematic for systems that require pre-delivery analysis (e.g. critical
systems) or systems developed by several teams.
TYPES OF REQUIREMENTS IN SE

 Functional Requirements – typically focus on the “what” of the system and identify the functions and data related
requirements.
 Non-functional Requirements – focus on the “how well” aspects of the system and identify attributes like

⚫ Performance
⚫ Maintainability
⚫ Inter-operability
⚫ Reliability
⚫ Portability
⚫ Constraints
FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS

• Functional requirements
• Statements of services the system should provide, how the system should react to particular
inputs and how the system should behave in particular situations.
• May state what the system should not do.
• Non-functional requirements
• Constraints on the services or functions offered by the system such as timing constraints,
constraints on the development process, standards, etc.
• Often apply to the system as a whole rather than individual features or services.
FUNCTIONAL REQUIREMENTS

• Describe functionality or system services.

• Depend on the type of software, expected users and the type of system where the software is used.
• Functional user requirements may be high- level statements of what the system should do.
• Functional system requirements should describe the system services in detail.
REQUIREMENTS IMPRECISION

• Problems arise when functional requirements are not precisely stated.

• Ambiguous requirements may be interpreted in different ways by
developers and users.
• Consider the term ‘search’ in requirement
• 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.
NON-FUNCTIONAL REQUIREMENTS

• These define system properties and constraints e.g. reliability, response time and storage requirements.
Constraints are I/O device capability, system representations, etc.

• Process requirements may also be specified mandating a particular IDE, programming language or
development method.

• Non-functional requirements may be more critical than functional requirements. If these are not met, the system
may be useless.
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, because of system and environmental complexity, it is impossible to

produce a complete and consistent requirements document.
NON FUNCTIONAL REQUIREMENTS IMPLEMENTATION

• Non-functional requirements may affect the overall architecture of a

system rather than the individual components.
• For example, to ensure that performance requirements are met, you may have to
organize the system to minimize communications between components.
• A single non-functional requirement, such as a security requirement,
may generate a number of related functional requirements that
define system services that are required.
• It may also generate requirements that restrict existing requirements.
NON-FUNCTIONAL CLASSIFICATION

• Product requirements
• Requirements which specify that the delivered product must behave in a particular way e.g.
execution speed, reliability, etc.
• Organizational requirements
• Requirements which are a consequence of organizational policies and procedures e.g. process
standards used, implementation requirements, etc.
• External requirements
• Requirements which arise from factors which are external to the system and its
development process e.g. interoperability requirements, legislative requirements, etc.
TYPES OF NON-FUNCTIONAL REQUIREMENTS
 https://www.youtube.com/watch?v=2L_6rBEMkdA
 WHAT IS “REQUIREMENTS ENGINEERING (RE) ”?

• The process of defining, documenting, and

maintaining requirements in the engineering
design process.
• Requirements are descriptions of what a
system should do, how it should behave, and
the constraints it must operate under.
THE REQUIREMENTS ENGINEERING PROCESS
A SPIRAL VIEW OF THE REQUIREMENTS ENGINEERING PROCESS
FEASIBILITY STUDIES

• A feasibility study decides whether or not the

proposed system is worthwhile
• A short focused study that checks
• If the system contributes to organisational
objectives
• If the system can be engineered using current
technology and within budget
• If the system can be integrated with other systems
that are used
FEASIBILITY TYPES /CATEGORIES

1. Technology and system feasibility

2. Economic feasibility
a. Cost-based study:
b. Time-based study:
3. Legal feasibility
4. Operational feasibility
5. Schedule feasibility
6. Market and real estate feasibility
7. Resource feasibility
8. Cultural feasibility
9. Financial feasibility
ACTIVITY: HOW TO WRITE FEASIBILITY REPORT

•A Ref:
http://www.mymanagementguide.com/feasibilit
y-study-reporting-steps-to-writing-a-feasibility-
study-report-fsr/
WHAT IS REQUIREMENTS ENGINEERING

• The establishment and use of sound

engineering principles to gather, analyze,
document and review software requirements
can be called software requirements
engineering.
Requirements engineering can be divided into
two main set of activities
• Requirements Definition
• Requirement Management
 REQUIREMENTS DEFINITION– AREAS

1. Requirements Elicitation or gathering of Requirements - collecting and identifying the

requirements for a system or project from various stakeholders, such as customers, end-users,
business analysts, and subject matter experts.

2. Requirements analysis or modeling - Requirements are gathered, modeled and analyzed

using modeling tools such as DFD, object oriented modeling techniques, ERD, etc.

3. Requirements documentation – Here the Requirements that are gathered and modeled are
put together in a document, typically know as the SRS

4. Requirements Review – This consists of, reviewing the SRS by all stakeholders. The reviewed
and approved SRS forms the basis for the work products to be created in the later parts of
the Software life cycle.
 REQUIREMENTS MANAGEMENT - AREAS

⚫ Change Management - This involves systematic handling of

changes to agreed requirement (SRS) during the course of the
project.
⚫ Requirements Traceability - This consists of maintaining
traceability of requirements between the agreed (and changed)
SRS and the other work products (like design documents and test
plans) created downstream in the SW life cycle, and upstream to
the origin of a requirement as well (backward traceability).
REQUIREMENT TRACEABILITY MATRIX
 REQUIREMENTS ELICITATION

Requirements elicitation is essentially a communications

process, involving different communities, or stakeholders .
Though elicitation primarily takes place at the start of the
project, an element of elicitation takes place through out the life
cycle.
⚫new requirements may be proposed during design and
implementation
⚫Existing requirements may be modified and deleted.
WHAT IS FACT FINDING

Consists of a study of the organization (?) in which the

target system will operate and for defining the proposed
system scope.

The problem scope definition activities involved in these

tasks are vague and open to interpretation. It is best to
have all the affected parties participate in this stage,
including users, developers and sponsors to promote
shared ownership.

“If everyone involved agrees upfront to the scope of the

system, the instability of requirements can be minimized”
REQUIREMENTS ELICITATION – FACT FINDING

• Identification of relevant users across multiple levels in the

user organization.
• Identification of analysts with relevant domain and technical
expertise
• Determination of scope or reconfirmation of the scope
• Identification of similar systems, if any
• Identification of domain and architectural models
• Conduct of technological survey, for later feasibility studies
and risk assessment
• Assessment of cost/implementation constraints imposed by
the sponsor.
 DOMAIN ANALYSIS

• The process by which a software engineer learns

about the domain to better understand the problem:
• The domain is the general field of business or technology in
which the clients will use the software
• A domain expert is a person who has a deep knowledge of
the domain

• Benefits of performing domain analysis:

• Faster development
• Better system
• Anticipation of extensions
DOMAIN ANALYSIS DOCUMENT

A. Introduction
B. Glossary
C. General knowledge about the domain
D. Customers and users
E. The environment
F. Tasks and procedures currently performed
G. Competing software
H. Similarities to other domains
DEFINING THE PROBLEM AND THE SCOPE

 A problem can be expressed as:

⚫A difficulty the users or customers are facing,
⚫Or as an opportunity that will result in some
benefit such as improved productivity or sales.

The solution to the problem normally will entail

developing software
 A good problem statement is short and succinct
 DEFINING THE SCOPE

• Narrow the scope by defining a more precise problem

• List all the things you might imagine the system doing
• Exclude some of these things if too broad
• Determine high-level goals if too narrow

• Example:A university registration system

Initial list of problems Narrowed Scope of

with very broad scope scope another system

browsing courses browsing courses

room allocation room allocation
registering registering
exam scheduling exam scheduling
fee payment
REQUIREMENTS ELICITATION

• Software engineers work with a range of system

stakeholders to find out about the application
domain, the services that the system should provide,
the required system performance, hardware
constraints, other systems, etc.
• Stages include:
• Requirements discovery,
• Requirements classification and organization,
• Requirements prioritization and negotiation,
• Requirements specification.
PROBLEMS OF REQUIREMENTS ELICITATION

• Stakeholders don’t know what they really want.

• Stakeholders express requirements in their own terms.
• Different stakeholders may have conflicting requirements.
• Organisational and political factors may influence the system requirements.
• The requirements change during the analysis process. New stakeholders may emerge and the business environment
may change.
THE REQUIREMENTS ELICITATION AND ANALYSIS PROCESS
PROCESS ACTIVITIES
• Requirements discovery
• Interacting with stakeholders to discover their requirements.
Domain requirements are also discovered at this stage.
• Requirements classification and organisation
• Groups related requirements and organises them into
coherent clusters.
• Prioritisation and negotiation
• Prioritising requirements and resolving requirements
conflicts.
• Requirements specification
• Requirements are documented and input into the next
round of the spiral.
GATHERING REQUIREMENTS – DISCOVERY

Captures information from the view point of various

users to identify what is to be built

 With the scope of the system understood, the next

task is to gather the requirements in more detail. The
requirements gathering exercise consists of

⚫ Creating a wish list for each user category across all levels
of the user community

⚫ Classify wish lists according to functional, and non-

functional, environment, and design constraints
REQUIREMENTS GATHERING TECHNIQUES

• In early stages of the requirements elicitation, it is important to gather as much

information as possible for users, developers and customers through the use of
• Interviews
• Observations
• Meetings
• Group discussion
• Simulations
• Questionnaires
• At times there are certain aspects about which information is not yet available
though the aspects are identified. Such Items are also included as “To be
Determined” (TBD). So that they remain visible and are noticed and resolved
before the requirements phase is considered complete.
INTERVIEWING

• Formal or informal interviews with stakeholders are part of

most RE processes.
• Types of interview
• Closed interviews based on pre-determined list of questions
• Open interviews where various issues are explored with stakeholders.
• Effective interviewing
• Be open-minded, avoid pre-conceived ideas about the requirements
and are willing to listen to stakeholders.
• Prompt the interviewee to get discussions going using a springboard
question, a requirements proposal, or by working together on a
prototype system.
INTERVIEWS IN PRACTICE

• Normally a mix of closed and open-ended

interviewing.
• Interviews are good for getting an overall
understanding of what stakeholders do and how they
might interact with the system.
• Interviewers need to be open-minded without pre-
conceived ideas of what the system should do
• You need to prompt the use to talk about the system
by suggesting requirements rather than simply asking
them what they want.
REQUIREMENT ELICITATION – EVALUATION

The requirements that have been gathered have to be evaluated to

resolve inconsistencies and also to understand why each requirement
has been stated.
• For every requirement X, get answers to question, “why do
you need X?”
• Convert any requirement stated as “How to” into the corresponding
“what” is required.
• Capture rationale to support further requirements.
• Perform risk assessment, feasibility and cost/benefit analysis
considering the technical, cost and schedule concerns
REQUIREMENTS ELICITATION - PRIORITIZATION

 Determines the relative importance of the

requirements
 The requirements are typically prioritized based on cost,
dependency, and user needs. Knowing the rationale
behind each requirement helps in deciding the priority.
⚫ Benefit to the user if the requirement is met. Another way of looking at this
parameter is to consider the loss of not having the requirement
⚫ Ease of Deployment, or how quickly and easily the requirement can be put into
operation once the computerized system is available. Factors to consider include
need for additional hardware, availability of data, user training requirement and
orientation/resistance of users to change from the existing system
REQUIREMENTS ELICITATION - PRIORITIZATION

• Ease of Development, of the requirement, in terms of

clarity, availability of development skills related to the
requirement, effort and the software development
environment required.
• Independence from other requirements, many
requirement may be easy to develop and deploy
provided some other requirements are implemented.
They however, will go down in priority as the
implementation is dependent on the implementation
of other requirement.
ELICITATION – REQUIREMENTS SPECIFICATION
• The process of writing down the user and system
requirements in a requirements document.
• User requirements have to be understandable by end-
users 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.
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 natural The requirements are written in natural language on a standard form or
language 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 These notations are based on mathematical concepts such as finite-state
specifications 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
REQUIREMENTS DEFINITION – REQUIREMENTS ANALYSIS

• Starts in parallel with requirement elicitation

• Objective:
⚫To identify inconsistencies, errors, omission and other defects
⚫To describe requirements in relationships
⚫To provide a basis for design
⚫To provide a basis for validation after software is built
• Based on the abstract system model(s)
REQUIREMENTS MODELING & ANALYSIS

• Usually done with the use of a systems modeling

technique(s)
• appropriate models for the proposed system
• Unified Modeling Language (UML) -
 Class Diagram
 Use Cases
 Activity Diagrams
• Data Flow Diagrams
• Entity Relationship Diagrams
CLASS DIAGRAM
USE CASES
ACTIVITY DIAGRAM
REQUIREMENTS ANALYSIS AND MODELING

• Facilitate to identify pointers where more elicitation

required

• Depiction of the scope of the system

• System Context Diagram

• Develop prototype(s)
REQUIREMENTS ELICITATION TECHNIQUE - PROTOTYPING

Acts as a vehicle for clarifying certain types of requirements

Should be carried out in a systematic manner

⚫ Establish Objectives for the prototype -

 Agree on the objectives of the prototype
 Minimize misunderstanding among stakeholders
 to discuss the user interface
 to establish technical feasibility
 to discuss functionality within a given context
 PROTOTYPING

⚫ Define prototype features and functionality (Scope)

 what will be in the prototype, but also state what will not be included in the
prototype.
 E.g. If the field level validations on screen will not be done then state so in
the document.
⚫ Get the prototype ready
 develop the prototype, review it against the list of features and
functionality, to ensure that all the required features and functionality
are developed.
 create a script containing a sequence of steps that will be executed on the
prototype during the evaluation step.
 PROTOTYPING

Evaluate the prototype

• review the goals, the features and function defined for the prototype to
establish the expectation of the prototype
• Collect Users’ and developers’ feedback based on the script
• Prepare the evaluation report which may includes
• new requirements
• changes to user interface
• dropping of requirements etc.
 PROTOTYPING – EVOLUTIONARY APPROACH

 Evolutionary Approach
⚫ The tools, language, platforms used to develop the prototype be the same as the actual
development platforms
⚫ To maximize the reuse of the prototype important conventions for the design and programming be
laid down before the development of the prototype begins
⚫ the prototype be reviewed not only externally (behavior) but also internally (design and code
review)
 PROTOTYPING – THROW AWAY APPROACH

Use of the prototype ends once all the requirements

are clearly documented
(not used for actual construction)
• The prototype is built using an environment and tools different from the tools and environment
that will be used to build the system

• Not much importance is given to the prototype’s “internals” such as coding standards

• the prototype is usually built very quickly as compared to evolutionary prototype

 PROTOTYPING – BENEFITS/DRAWBACKS
 Benefits
 Improved communication between the developers and the end users
 Increased user involvement
 Ability to clarify hidden or ambiguous requirements
 Quicker review of the SRS
 Better expectation setting of end user
 Drawbacks
⚫ disillusioned with a prototype since the prototype is not as robust as the system and does not contain the full
functionality
⚫ A user may think that the system is ready by looking at the prototype and may think that the developers are
taking him for a ride by asking for a considerable amount of additional time (misunderstanding).
⚫ Developers may use “prototype” as an excuse to hack code rather than to get requirements.
⚫ The cost of prototyping is added to the project
⚫ Developers may start considering the prototype as a substitute for the documented SRS
REQUIREMENTS DEFINITION – REQUIREMENTS DOCUMENTATION

Most important work products

• Customers/users for understanding what they are supposed to get
• Project managers to estimate and plan the project to deliver the system.
• Designers and programmers to know what to build.
• Testers to prepare testing activities
• Maintenance teams for understanding the system that they will maintain
• Trainers to prepare training material for training the end users
• Users to understand the proposed system and prepare for the change
over.
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.
REQUIREMENTS DOCUMENTATION

SRS – Software Requirement

Specification
• Produced as the result of elicitation and analysis
• Documented in combination of
• Natural Languages (textual narratives)
• Schematic and formal specification language
• Graphical Models

• SRS should include all requirements

• No implied/obvious requirements
REQUIREMENTS DOCUMENT

• Information in requirements document depends

on type of system and the approach to
development used.
• Systems developed incrementally will, typically,
have less detail in the requirements document.
• Requirements documents standards have been
designed e.g. IEEE standard. These are mostly
applicable to the requirements for large systems
engineering projects.
THE STRUCTURE OF REQUIREMENTS DOCUMENT

Chapter Description
Preface This should define the expected readership of the document and describe its
version history, including a rationale for the creation of a new version and a
summary of the changes made in each version.

Introduction This should describe the need for the system. It should briefly describe the
system’s functions and explain how it will work with other systems. It should
also describe how the system fits into the overall business or strategic
objectives of the organization commissioning the software.

Glossary This should define the technical terms used in the document. You should not
make assumptions about the experience or expertise of the reader.

User requirements Here, you describe the services provided for the user. The nonfunctional system
definition requirements should also be described in this section. This description may use
natural language, diagrams, or other notations that are understandable to
customers. Product and process standards that must be followed should be
specified.

System architecture This chapter should present a high-level overview of the anticipated system
architecture, showing the distribution of functions across system modules.
Architectural components that are reused should be highlighted.
THE STRUCTURE OF A REQUIREMENTS DOCUMENT
Chapter Description
System This should describe the functional and nonfunctional requirements in more detail.
requirements If necessary, further detail may also be added to the nonfunctional requirements.
specification Interfaces to other systems may be defined.
System models This might include graphical system models showing the relationships between
the system components and the system and its environment. Examples of
possible models are object models, data-flow models, or semantic data models.

System evolution This should describe the fundamental assumptions on which the system is based,
and any anticipated changes due to hardware evolution, changing user needs,
and so on. This section is useful for system designers as it may help them avoid
design decisions that would constrain likely future changes to the system.
Appendices These should provide detailed, specific information that is related to the
application being developed; for example, hardware and database descriptions.
Hardware requirements define the minimal and optimal configurations for the
system. Database requirements define the logical organization of the data used
by the system and the relationships between data.
Index Several indexes to the document may be included. As well as a normal alphabetic
index, there may be an index of diagrams, an index of functions, and so on.
REQUIREMENTS DOCUMENTATION – SRS
CHARACTERISTICS

 Completeness –
⚫ requirements from all the stakeholders
⚫ More than the system functionality
⚫ Focusing on user tasks, problems, bottlenecks and improvements required

⚫Ranking/Prioritizing Requirements
⚫ Customers identifies most important ones
⚫ Designers to make right trade-offs
⚫ Scope Matrix
REQUIREMENTS DOCUMENTATION – SRS CHARACTERISTIC

• Clarity –
• The documented requirements should lead to
only a single interpretation independent of the
person or the time

• Minimize the use of natural languages

• Use requirement specification language

REQUIREMENTS DOCUMENTATION – SRS CHARACTERISTIC

⚫Readability
 Consistently number chapters, sections and sub
sections and individual requirements
 Align text to the left margin rather than “justify both
margins”
 Use white space to reduce eye strain
 Use highlighting features
 Do not use colors as far as possible
 Create a table of contents
 Use hyperlinks within the document to easy navigation
REQUIREMENTS DOCUMENTATION – SRS CHARACTERISTIC

Correctness
⚫ every requirement stated must be actual required by the system.

Consistency – There should not be any

conflicts in the requirements
 Characteristics of a real world entity interacting with the system may be
conflicting.

 There may be logical or temporal conflict between two specified items.

REQUIREMENTS DOCUMENTATION – SRS CHARACTERISTIC

Modifiability
⚫ Changes can be made to SRS
⚫ Changes can be traced

Certain good practices that can lead to high modifiability are

Minimal redundancy
labels and references to figures, tables,
diagrams and appendices in the SRS
REQUIREMENTS DOCUMENTATION – SRS CHARACTERISTIC

Traceability
Labeling (or numbering) of requirements provides a mechanism to
trace each requirement through the design into the test plans, test
cases and source code.
 Backward traceability to the documentation/and other work-
products created prior to the requirements phase. This will
depend upon how well referencing and labeling has been
provided in the earlier documents/ work products
 Forward traceability – This will depend upon on how each
requirement is labeled or numbered. Forward traceability is
extremely important as this is one of the way of tracing a
requirement to its implementation.
REQUIREMENTS DOCUMENTATION – SRS CHARACTERISTIC

• Feasibility
• Highlight infeasible requirements
• put out of the SRS after providing the proper reasons

• Testability
• Every requirement in SRS to be tested (need the test case)
• Typically statements like “user friendly”, “reasonable
response”, “fairly accurate” are non-testable and non-
verifiable. These need to be identified and removed from
the SRS.
EXAMPLES – HOW TO WRITE REQUIREMENTS

1. The user shall be able to search the

appointment list for a given date
2. The system shall generate each day, for each
clinic, a list of patients who are expected to
attend appointments on that day
3. Each staff member using the system shall be
uniquely identified by his or her employee
number
COMMON PROBLEMS WITH SRS

 Making bad assumptions

 Writing implementation (How) instead of requirements (What)

 Stating implementation details forces a design approach when not

intended. In addition by stating implementation, the author may be
lulled into believing that all requirements are covered. In fact some
very important requirements can be missing and the provider can
deliver what is asked for or still not deliver what is needed.

 Using incorrect terms – In a specification there are terms to be

avoided and terms must be used in a very specific manner. Authors
need to understand the use of shall, will and should
COMMON PROBLEMS WITH SRS

⚫ Requirements use shall

⚫ Statement of fact use will
⚫ Goals use should
These are standard terms used in contract and process documents. Deviation from this
usage will create confusion.
⚫ Terms such as
 Are
 Is
 Was
 Must – do not belong in a requirement.
⚫ Other terms to be avoided in writing requirements because they confuse the issue
are
 Support
 But not limited to
 Etc.
 And/or
Etc and “But not limited to” are listed since the writer expects more
COMMON PROBLEMS WITH SRS

• Using wrong language – Requirements should

be easy to read and understand. The
requirements in a system specification are
either for the system or its next level, e.g.
sub-system. Each requirement can usually be
written in the format
• The System shall provide
• The system shall be capable of
• The system shall weigh
• The subsystem shall provide
• The subsystem
COMMON PROBLEMS WITH SRS

• Unverifiable requirements – Every requirement should be verifiable (testable)

ambiguous terms like the following terms should be avoided since they
provide a different meaning to different people.
• Minimize
• Maximize
• User friendly
• Easy
• Sufficient
• Adequate
• Quick
• Fast
• Enough
• Sometimes
• And Often
COMMON PROBLEMS WITH SRS

• Missing Requirements
• Over Specifying
• Unnecessary requirements creep into
specification in a number of ways and the
only cure is to carefully manage, review and
control
THANK YOU