Chapter 3-5: Requirements Engineering Task, Requirements Analysis, Requirements Specification

Chapter 3-5:
Requirements Engineering Task,

Requirements Analysis,
Requirements Specification.
Alamirew Gedif
Learning Objectives
 At the completion of this chapter, you are able to identify and
understand the following concepts as
 Requirement gathering
Inception
Elicitation
 Requirement analysis
Elaboration
Negotiation
Validation
 Requirement specification
Specification document preparation
 Requirement Traceability and Traceability Matrix
CT-3212: Chapter 3 - Requirement Engineering 2

Requirements Engineering
• Requirements engineering helps software engineers understand the
problem they are to solve. It involves activities that lead to
understanding the business context, what the customer wants, how
end-users will interact with the software, and what the business
impact will be.
• Requirements engineering starts with the problem definition:
customer statement of work (also known as customer statement of
requirements). This is an informal description of what the customers
think they need from a software system to do for them. The problem
could be identified by management personnel, through market
research, by ingenious observation, or some other means. (This is
called inception).
• Defining the requirements for the system-to-be includes both fact-
finding about how the problem is solved in the current practice as well
as envisioning how the planned system might work. The final outcome
of requirements engineering is a requirements specification
document. CT-3212: Chapter 3 - Requirement Engineering 3
• The key task of requirements engineering is formulating a well-defined
problem to solve.
• A well defined problem includes
– A set of criteria (“requirements”) according to which proposed
solutions either definitely solve the problem or fail to solve it
– The description of the resources and components at disposal to
solve the problem.
• Requirements engineering involves different stakeholders in defining
the problem and specifying the solution. A stakeholder is an individual,
team, or organization with interests in, or concerns related to, the
system-to-be. Generally, the system-to-be has several types of
stakeholders: customers, end users, business analysts, systems
architects and developers, testing and quality assurance engineers,
project managers, the future maintenance organization, owners of
other systems that will interact with the system-to-be, etc.
• The stakeholders all have a stake, but the stakes may differ. End users
will be interested in the requested functionality. Architects and
developers will be interested in how to effectively implement this
functionality. Customers will be interested in costs and timelines.
Often compromises and tradeoffs need to be made to satisfy different
stakeholders.
• Although different methodologies provide different techniques for
requirements engineering, all of them follow the same requirements
process:
– requirements gathering,
– requirements analysis, and
– requirements specification.

Requirements Engineering: Requirement Gathering
• Requirements Gathering (also known as “requirements elicitation”)
helps the developer understand the business context.
• The customer needs to define what is required: what is to be
accomplished, how the system will fit into the needs of the business,
and how the system will be used on a day-to-day basis.
• The statement of work is rarely precise and complete enough for the
development team to start working on the software product.
 Requirements Gathering Strategies
• If the developer is lucky, the customer will arrive with a clear
statement of work that needs to be done (“customer statement of
requirements”). In reality, this rarely happens. Requirements for the
system-to-be should be devised based on observing the current
practice and interviewing the stakeholders, such as end users,
managers, etc. To put it simply, you can’t fix it if you don’t know what’s
broken. Structured interviews help in understanding what stakeholders
do, how they might interact with the planned system, and the
difficulties they are facing with the existing technology.
• Agile methodologists recommend that the customers or users stay
continuously involved throughout the project duration, instead of only
providing the requirements initially and disappearing until the system
is completed.
• How to precisely specify what system needs to do is a problem, but
sometimes it is even more difficult to get the customer to say what he
or she expects from the system. Gathering domain knowledge by
interviews is difficult because domain experts use terminology and
jargon specific to their domain that is unfamiliar and hard for an
outsider to grasp.
• In addition, it is often difficult for the user to imagine the work with a
yet-to-be-built system.

• Sommerville and Sawyer suggest a set of detailed Guidelines for
Requirements Elicitation, which are stated in the following steps:
– Assess the business and technical feasibility
– Identify the people who will help specify requirements and
understand their organizational bias.
– Define the technical environment (computing architecture,
operating system, telecommunications needs) into which the
system or product will be placed.
– Identify domain constraints that limit the functionality or
performance of the system or product to be built.
– Define one or more requirements elicitation methods.
– Solicit participation from many people so that requirements are
defined from different points of view; be sure to identify the
rationale for each requirement that is recorded.
– Identify ambiguous requirements as candidates for prototyping.
– Create usageCT-3212:
scenarios to help customers/users better identify8key
Chapter 3 - Requirement Engineering
requirements.
Requirements Engineering: Analysis
• Requirements analysis involves refining of and reasoning about the
requirements received from the customer during requirements
gathering.
• Analysis is driven by the creation and elaboration of user scenarios
that describe how the end-user will interact with the system.
• Negotiation with the customer will be needed to determine the
priorities, what is essential, and what is realistic.
• A popular tool is the use cases. It is important to ensure that the
developer’s understanding of the problem coincides with the
customer’s understanding of the problem.
• Given the statement of work, the first step in the software
development process is called requirements analysis or systems
analysis. During this activity the developer attempts to understand the
problem and delimit its scope. The result is an elaborated statement
of requirements. The goal is to produce the system specification—the
document that is an exact description of what the planned system-to-
be is to do. CT-3212: Chapter 3 - Requirement Engineering 9
• Requirements analysis delimits the system and specifies the services
it offers, identifies the types of users that will interact with the
system, and identifies other systems that interact with ours.
• Requirement analysis includes both fact-finding of how the problem is
solved in the current practice as well as envisioning how the planned
system might work.
• A popular technique for requirements analysis is use case modeling. A
set of use cases describes the elemental tasks a system is to perform
and the relation between these tasks and the outside world. Each use
case description represents a dialog between the user and the system,
with the aim of helping the user achieve a business goal. In each
dialog, the user initiates actions and the system responds with
reactions. The use cases specify what information must pass the
boundary of the system in the course of a dialog (without considering
what happens inside the system).

• Because use cases represent recipes for user achieving goals, each
use-case name must include a verb capturing the goal achievement.
Use cases are only a beginning of software engineering process. When
we elaborate use cases of a system, it signifies that we know what the
system needs to accomplish, not how; therefore, it is not just “a small
matter of system building” (programming) that is left after we specify
the use cases. Requirements analysis is detailed as required.
 Software requirements analysis may be divided into five areas of
effort: problem recognition, problem evaluation and solution
synthesis, modeling, specification, and review.
• Initially, It is important to understand software in a system context
and to review the software scope that was used to generate planning
estimates.
• Next, communication for analysis must be established so that problem
recognition is ensured.
• The goal is recognition of the basic problem elements as perceived by
the customer/users.
• In the process of problem evaluation and solution synthesis effort
for analysis, the analyst must define all externally observable data
objects, evaluate the flow and content of information, define and
elaborate all software functions, understand software behavior in
the context of events that affect the system, establish system
interface characteristics, and uncover additional design
constraints. Each of these tasks serves to describe the problem so
that an overall approach or solution may be synthesized.
• Upon evaluating current problems and desired information (input
and output), the analyst begins to synthesize one or more
solutions. To begin, the data objects, processing functions, and
behavior of the system are defined in detail. Once this information
has been established, basic architectures for implementation are
considered.
• The process of evaluation and synthesis continues until both
analyst and customer feel confident that software can be
adequately specified for subsequent development steps.
CT-3212: Chapter 4 - Requirements Analysis and Modeling 12
• Throughout evaluation and solution synthesis, the analyst's primary
focus is on "what," not "how." What data does the system consume
and produce, what functions must the system perform, what
behaviors does the system exhibit, what interfaces are defined and
what constraints apply?
• During the evaluation and solution synthesis activity, the analyst
creates models of the system in an effort to better understand data
and control flow, functional processing, operational behavior, and
information content. The model serves as a foundation for software
design and as the basis for the creation of specifications for the
software.
• You should note that detailed specifications may not be possible at
analysis stage. The customer may be unsure of precisely what is
required. The developer may be unsure that a specific approach will
properly accomplish function and performance.
• For these, and many other reasons, an alternative approach to
requirements analysis, called modeling, may be conducted. 13
CT-3212: Chapter 4 - Requirements Analysis and Modeling
 Activities during modeling analysis are:
• Identifying actors. During this activity, developers identify the
different types of users the future system will support.
• Identifying scenarios. During this activity, developers observe users
and develop a set of detailed scenarios for typical functionality
provided by the future system. Scenarios are concrete examples of
the future system in use. Developers use these scenarios to
communicate with the user and deepen their understanding of the
application domain.
• Identifying use cases. Once developers and users agree on a set of
scenarios, developers derive from the scenarios a set of use cases
that completely represent the future system. Whereas scenarios are
concrete examples illustrating a single case, use cases are
abstractions describing all possible cases. When describing use
cases, developers determine the scope of the system.
• Refining use cases. During this activity, developers ensure that the
requirements specification is complete by detailing each use case
and describing the behavior of the system in the presence of errors
and exceptional conditions.
• Identifying relationships among use cases. During this activity,
developers identify dependencies among use cases. They also
consolidate the use case model by factoring out common
functionality. This ensures that the requirements specification is
consistent.
• Identifying nonfunctional requirements. During this activity,
developers, users, and clients agree on aspects that are visible to
the user, but not directly related to functionality. These include
constraints on the performance of the system, its documentation,
the resources it consumes, its security, and its quality.

 Requirements Elaboration
• The elaboration phase continues with developing the vision
document, including finalizing the business case, revising the risk
assessment, and completing a project plan in sufficient detail to
allow the stakeholders to be able to agree with constructing the
actual final system.
• It deals with gathering the requirements, building the UML
structural and behavioral models of the problem domain, and
detailing how the problem domain models fit into the evolving
system architecture.
• The primary deliverables of this phase include the UML structure
and behavior diagrams and an executable of a baseline version of
the evolving information system. The baseline version serves as the
foundation for all later iterations.

• The elaboration phase usually involves several iterations, and early
iterations typically complete the identification and definition of all of
the system requirements. The requirements are expected to evolve
and change after work starts on the project.
• Elaboration phase iterations also complete the analysis, design, and
implementation of the core architecture of the system. Until
developers know exactly how the highest-risk aspects of the project
will work out, they cannot determine the amount of effort required
to complete the project.
• By the end of the elaboration phase, the project manager should
have more realistic estimates for a project’s cost and schedule, and
the business case for the project can be confirmed.
• The design, implementation, and testing of key parts of the system
are completed during the elaboration phase.

• The elaboration phase focuses on several iterations that take part
of the system and define the requirements, design the solution,
and implement the solution.
• The team defines the requirements and the design by creating use
case diagrams, class diagrams, sequence diagrams, and other UML
diagrams.
• Final cost and benefit estimates are completed by the end of the
elaboration phase.

 Requirements Negotiation and Validation
• Requirements elicited from customers may overlap or conflict.
Some requirements may be ambiguous or unrealistic. Others may
remain undiscovered. For these reasons, requirements need to be
negotiated and validated before they find their way into the
requirements document.
• In reality, requirements negotiation and validation are done in
parallel with requirements elicitation.
• As requirements are elicited, they are subjected to a certain
degree of scrutiny (critical observation or examination).
Nevertheless, once the elicited requirements have been compiled
into a list, they still need to undergo careful negotiation and
validation.

• Requirements negotiation and validation cannot be dissociated
from the process of writing up a requirements document.
Requirements negotiation is typically based on a draft of the
document.
• The requirements listed in the draft document are negotiated and
modified, if necessary. Spurious (false or fake) requirements are
removed. Newly discovered requirements are added.
• Requirements validation requires a more complete version of the
requirements document, with all the requirements clearly
identified and classified. Stakeholders read the document and
conduct formal review meetings. Reviews are frequently structured
into so called walkthroughs or inspections. They are a form of
testing.

• Disagreements about requirements are inevitable when a system
has many stakeholders. Conflicts are not ‘failures’ but reflect
different stakeholder needs and priorities
• Requirements negotiation is the process of discussing
requirements conflicts and reaching a compromise that all
stakeholders can agree to.
• In planning a requirements engineering process, it is important to
leave enough time for negotiation. Finding an acceptable
compromise can be time-consuming.
• The final requirements will always be a compromise which is
governed by the needs of the organization in general, the specific
requirements of different stakeholders, design and
implementation constraints, and the budget and schedule for the
system development.

 Requirements Negotiation Stages
– Requirements discussion
– Requirements prioritization
– Requirements agreement
• Requirements Discussion
– Requirements which have been highlighted as problematic are
discussed and the stakeholders involved present their views about
the requirements
• Requirements Prioritization
– Disputed requirements are prioritized to identify critical
requirements and to help the decision making process
• Requirements Agreement
– Solutions to the requirements problems are identified and a
compromised set of requirements are reached. Generally, this will
involve making changes to some of the requirements
 Resolution of Requirements Conflicts
– Meetings are the most effective way to negotiate requirements and
resolve requirements conflicts
– All requirements which are in conflict should be discussed individually
– Negotiation meetings should be conducted in three stages
 Stages of Negotiation Meetings
– Information stage
– Discussion stage
– Resolution stage
• Information Stage
– An information stage where the nature of the problems associated
with a requirement is explained
• Discussion Stage
– A discussion stage where the stakeholders involved discuss how these
problems might be resolved
– All stakeholders with an interest in the requirement should be given
the opportunity to comment. Priorities may be assigned 23 to
requirements at this stage.

• Resolution Stage
– A resolution stage where actions concerning the requirement
are agreed
– These actions might be to delete the requirement, to suggest
specific modifications to the requirement or to elicit further
information about the requirement
• Up-till Now
– Interaction matrices are very useful for capturing interactions
among requirements
– Requirements negotiation is always necessary to resolve
requirements conflicts and remove requirements overlaps.
Negotiation involves information interchange, discussion and
resolution of disagreements

• The work products produced as a consequence of requirements
engineering are assessed for quality during a validation step.
• Requirements validation examines the specification to ensure that
– all system requirements have been stated unambiguously;
– inconsistencies, omissions, and errors have been detected and
corrected; and
– the work products conform to the standards established for the
process, the project, and the product.
• The primary requirements validation mechanism is the formal
technical review.
• The review team includes system engineers, customers, users, and
other stakeholders who examine the system specification looking for
errors in content or interpretation, areas where clarification may be
required, missing information, inconsistencies requirements.

• Requirements validation is the process of checking that
requirements actually define the system that the customer really
wants.
– It overlaps with analysis as it is concerned with finding problems
with the requirements.
• Requirements validation is important because errors in a
requirements document can lead to extensive rework costs when
these problems are discovered during development or after the
system is in service.
• The cost of fixing a requirements problem by making a system
change is usually much greater than repairing design or coding
errors.
– The reason for this is that a change to the requirements usually
means that the system design and implementation must also be
changed. Furthermore the system must then be re-tested.
• Requirements validation is the process of checking that
requirements actually define the system that the customer really
wants. It overlaps with analysis as it is concerned with finding
problems with the requirements.
• Requirements validation is important because errors in a
requirements document can lead to extensive rework costs when
these problems are discovered during development or after the
system is in service. The cost of fixing a requirements problem by
making a system change is usually much greater than repairing
design or coding errors. The reason for this is that a change to the
requirements usually means that the system design and
implementation must also be changed. Furthermore the system
must then be re-tested.
• During the requirements validation process, different types of
checks should be carried out on the requirements in the
• These checks include:
– Validity checks- a system is needed to perform certain functions.
However, further thought and analysis may identify additional or
different functions that are required. Systems have diverse
stakeholders with different needs and any set of requirements is
inevitably a compromise across the stakeholder community.
– Consistency checks- Requirements in the document should not
conflict. That is, there should not be contradictory constraints or
different descriptions of the same system function.
– Completeness checks- The requirements document should
include requirements that define all functions and the
constraints intended by the system user.

– Realism checks-Using knowledge of existing technology, the
requirements should be checked to ensure that they can actually
be implemented. These checks should also take account of the
budget and schedule for the system development.
– Verifiability-To reduce the potential for dispute between
customer and contractor, system requirements should always be
written so that they are verifiable. This means that you should
be able to write a set of tests that can demonstrate that the
delivered system meets each specified requirement.

 Requirements Management
• The requirements for large software systems are always
changing. One reason for this is that these systems are usually
developed to address ‘wicked’ problems—problems that cannot
be completely defined. Because the problem cannot be fully
defined, the software requirements are bound to be incomplete.
During the software process, the stakeholders’ understanding of
the problem is constantly changing. The system requirements
must then also evolve to reflect this changed problem view.
• Once a system has been installed and is regularly used, new
requirements inevitably emerge. It is hard for users and system
customers to anticipate what effects the new system will have on
their business processes and the way that work is done.
• Once end users have experience of a system, they will discover
new needs and priorities.
 There are several reasons why change is inevitable:
1. The business and technical environment of the system always changes
after installation. New hardware may be introduced, business
priorities may change, and new legislation and regulations may be
introduced that the system must necessarily abide by.
2. The people who pay for a system and the users of that system are
rarely the same people. System customers impose requirements
because of organizational and budgetary constraints. These may
conflict with end-user requirements and, after delivery, new features
may have to be added for user support if the system is to meet its
goals.
3. Large systems usually have a diverse user community, with many
users having different requirements and priorities that may be
conflicting or contradictory.
• The final system requirements are inevitably a compromise between
them. Requirements management is the process of understanding
and controlling changes to system requirements.
Requirements Engineering: Specification
• Requirements specification represents the problem statement in a
semiformal or formal manner to ensure clarity, consistency, and
completeness.
• It describes the function and quality of the software-to-be and the
constraints that will govern its development.
 A specification can be a written document, a set of graphical models, a
formal mathematical model, a collection of usage scenarios (or, “use
cases”), a prototype, or any combination of these. The developers
could use UML or another symbol language for this purpose.
• In the context of computer-based systems (and software), the term
specification means different things to different people. A
specification can be a written document, a graphical model, a formal
mathematical model, a collection of usage scenarios, a prototype, or
any combination of these.
• Requirements specification is the process of writing down the user
and system requirements in a requirements document.
• Ideally, the user and system requirements should be clear,
unambiguous, easy to understand, complete, and consistent. In
practice, this is difficult to achieve as stakeholders interpret the
requirements in different ways and there are often inherent conflicts
and inconsistencies in the requirements.
• It is an official statement of what the system developers should
implement. It should include both the user requirements for a system
and a detailed specification of the system requirements. Sometimes,
the user and system requirements are integrated into a single
description.
• System requirements are expanded versions of the user requirements
that are used by software engineers as the starting point for the
system design. They add detail and explain how the user requirements
should be provided by the system. They may be used as part of the
contract for the implementation of the system and should therefore
be a complete and detailed specification of the whole system.
• The System Specification is the final work product produced by the
system and requirements engineer. It serves as the foundation for
hardware engineering, software engineering, database engineering,
and human engineering.
• It describes the function and performance of a computer-based system
and the constraints that will govern its development.
• The specification bounds each allocated system element. The System
Specification also describes the information that is input to and output
from the system.
• The requirements document has a diverse set of users, ranging from
the senior management of the organization that is paying for the
system to the engineers responsible for developing the software.
• The diversity of possible users means that the requirements document
has to be a compromise between communicating the requirements to
customers, defining the requirements in precise detail for developers
and testers, and including information about possible system
evolution. CT-3212: Chapter 5 - Requirements Specification 34
• User requirements are almost always written in natural language
supplemented by appropriate diagrams and tables in the requirements
document. System requirements may also be written in natural
language but other notations based on forms, graphical system
models, or mathematical system models can also be used.
• Graphical models are most useful when you need to show how a state
changes or when you need to describe a sequence of actions. Formal
mathematical specifications are sometimes used to describe the
requirements for safety-or security-critical systems.
CT-3212: Chapter 5 - Requirements Specification 35

• As mentioned, logical ordering of the development lifecycle does not
imply that we must achieve perfection in one stage before we
progress to the next one. Quite opposite, the best results are
achieved by incremental and iterative attention to different stages of
the requirements engineering process. This is an important lesson of
the agile development philosophy.
• Traditional prescriptive processes are characterized by their heavy
emphasis on getting all the requirements right and written early in
the project.
• Agile projects, on the other hand, acknowledge that it is impossible
to identify all the requirements in one pass. Agile software
development introduced a light way to model requirements in the
form of user stories, which are intended to capture customer needs,
and are used to estimate effort and plan releases.

Requirement Classification
 Functional requirements
• The functional requirements for a system describe what the system
should do. These requirements depend on the type of software
being developed, the expected users of the software, and the
general approach taken by the organization when writing
requirements.
• When expressed as user requirements, functional requirements are
usually described in an abstract way that can be understood by
system users.
• However, more specific functional system requirements describe
the system functions, its inputs and outputs, exceptions, etc., in
detail.
• Functional system requirements vary from general requirements
covering what the system should do to very specific requirements
reflecting local ways of working or an organization’s existing
systems.
• In principle, the functional requirements specification of a system
should be both complete and consistent. Completeness means that
all services required by the user should be defined. Consistency
means that requirements should not have contradictory definitions.
• In practice, for large, complex systems, it is impossible to achieve
requirements consistency and completeness. The reason for this is
that there are many stakeholders in a large system.
• Stakeholders have different—and often inconsistent—needs. These
inconsistencies may not be obvious when the requirements are first
specified, so inconsistent requirements are included in the
specification.
• The problems may only emerge after deeper analysis or after the
system has been delivered to the customer.

 Non-functional requirements
• Describe aspects of the system that are not directly related to the
functional behavior of the system. Nonfunctional requirements
include a broad variety of requirements that apply to many different
aspects of the system, from usability to performance.
 The categories of nonfunctional requirements are:
• Usability
– is the ease with which a user can learn to operate, prepare
inputs for, and interpret outputs of a system or component.
Usability requirements include, for example, conventions
adopted by the user interface, the scope of online help, and the
level of user documentation. Often, clients address usability
issues by requiring the developer to follow user interface
guidelines on color schemes, logos, and fonts.

• Reliability
– the ability of a system or component to perform its required
functions under stated conditions for a specified period of time.
– Reliability requirements include, for example, an acceptable mean
time to failure and the ability to detect specified faults or to
withstand specified security attacks.
– More recently, reliability is replaced by dependability, which
includes reliability, robustness (the degree to which a system or
component can function correctly in the presence of invalid inputs
or stressful environment conditions), and safety (a measure of the
absence of catastrophic consequences to the environment).
• Performance requirements
– concerned with quantifiable attributes of the system, such as
response time (how quickly the system reacts to a user input),
throughput (how much work the system can accomplish within a
specified amount of time), availability (the degree to which a
system or component is 3operational
CT-3212: Chapter and accessible when required
- Requirement Engineering 40
for use), and accuracy.
• Supportability requirements
– concerned with the ease of changes to the system after
deployment, including for example,
• adaptability (the ability to change the system to deal with
additional application domain concepts),
• maintainability (the ability to change the system to deal with
new technology or to fix defects), and
• internationalization (the ability to change the system to deal
with additional international conventions, such as languages,
units, and number formats).
• Information security requirements
– Owing to different types of information use, there are two main
security disciplines-communication security and computer
security. Communication security is concerned with protecting
information when it is being transported between different
systems. CT-3212: Chapter 3 - Requirement Engineering 41
• Computer security is related to protecting information within a
single system, where it can be stored, accessed, and processed.
Notice that both communication and computer security must be
complemented with physical (building) security as well as personnel
security.
• The main objectives of information security are:
– Confidentiality: ensuring that information is not disclosed or
revealed to unauthorized persons
– Integrity: ensuring consistency of data, in particular, preventing
unauthorized creation, modification, or destruction of data
– Availability: ensuring that legitimate users are not unduly denied
access to resources, including information resources, computing
resources, and communication resources
– Authorized use: ensuring that resources are not used by
unauthorized persons or in unauthorized ways.
Requirement Traceability
• Software products are increasingly being deployed in complex,
potentially dangerous products such as weapons systems, aircraft,
and medical devices. Software products are critical because failure in
these areas could result in loss of life, significant environmental
damage, and major financial loss. This might lead one to believe that
care would be taken to implement these software products using
proven, reproducible methods. Unfortunately, this is not always the
case.
• One feature that software development standards have in common
is that they all impose requirements traceability practices on the
software development process.
• Requirements traceability can be defined as “the ability to describe
and follow the life of a requirement, in both a forward and backward
direction”

• The IEEE defines traceability as “the degree to which a relationship
can be established between two or more products of the
development process, especially products having a predecessor-
successor or master-subordinate relationship to one another.”
• Traceability is used to track the relationship between each unique
product-level requirement and its source.
– For example, a product requirement might trace from a business
need, a user request, a business rule, an external interface
specification, an industry standard or regulation, or to some
other source.
• Traceability is also used to track the relationship between each
unique product-level requirement and the work products to which
that requirement is allocated.
– For example, a single product requirement might trace to one or
more architectural elements, detail design elements,
objects/classes, code units, tests, user documentation topics,
and/or even to people or manual processes that implements that
requirement.
• Research has shown that inadequate traceability is an important
contributing factor to software project failures and budget overruns.
As a response, there has been an outpouring of research and
literature on the subject of traceability, and many organizations have
been striving to improve their traceability practices.
• Although the importance of traceability seems to be well-accepted in
the software engineering industry, research suggests that many
organizations still do not understand the principles of traceability
and are struggling with implementing traceability practices in the
software development life cycle. Perhaps the biggest need is for a
better understanding of why traceability is important and the
challenges facing its implementation.

• Requirements traceability ensures that each business need is tied to
an actual requirement, and that each requirement is tied to a
deliverable. This is a valuable practice for the business analyst.
According to A Guide to the Business Analyst’s Body of Knowledge,
(BABOK), all requirements are “related to other requirements, to
solution components, and to other artifacts such as test cases. . . .
• The goal of tracing is to ensure that requirements (and ultimately,
solution components) are linked back to a business objective.” In
other words, traceability ensures that every requirement has a
business purpose, and that no requirement is superfluous.
• A requirement may be traced in one of four distinct ways, according
to Karl Weigers in his book ‘Software Requirements.

– “Customer needs are traced forward to requirements, so that
you can tell which requirements will be affected if those needs
change.
– Conversely, you can trace backward from requirements to
customer needs to identify the origin of each software
requirement.
– You can trace forward from requirements by defining links
between individual requirements and specific product elements.
– Specific product elements [may be traced] backward to
requirements so that you know why each item was created.”

• Generally summarized as, good traceability practices allow for
bidirectional traceability, meaning that the traceability chains can be
traced in both the forwards and backwards directions.
• Forward traceability looks at:
– Tracing the requirements sources to their resulting product
requirement(s) to ensure the completeness of the product
requirement specification.
– Tracing each unique product requirement forward into the
design that implements that requirement, the code that
implements that design and the tests that validate that
requirement and so on. The objective is to ensure that each
requirement is implemented in the product and that each
requirement is thoroughly tested.

• Backwards traceability looks at:
– Tracing each unique work product (e.g., design element,
object/class, code unit, test) back to its associated requirement.
Backward traceability can verify that the requirements have been
kept current with the design, code, and tests.
– Tracing each requirement back to its source(s).

The Importance of Traceability
• Tracing requirements, when done properly, saves time, money, and
effort on the part of the analyst, the project sponsors and the parent
organization. Business analysis experts have detailed the following
benefits of requirements traceability:
 It ensures that final deliverables directly tie to initial business needs.
Forward requirements traceability offers an analyst a means to be sure
that business needs are tied to actual requirements, and that actual
requirements are tied to deliverables. (Therefore, each business need is
tied to a deliverable.) Conversely, backward traceability ensures that if
a product feature is developed that no one remembers asking for or
authorizing, the analyst can determine whether it is simply a case of
gold-plating or if it is indeed tied to a requirement (and corresponding
business need). According to BABOK, “When business objectives are
traced to detailed requirements such as business rules, data elements,
and use cases, it is clear how they will be accomplished. Each business
objective can be reviewed to make sure that it will be addressed by the
appropriate solution components.”
 Done properly, it ensures that organizations do not waste time and
resources repeating research. Without requirements traceability,
organizations have the potential to waste a lot of money on
backtracking, duplicate research, and lost business needs. In their
article, “Why Software Requirements Traceability Remains a
Challenge,” authors Andrew Kannenberg and Dr. Hossein Saiedian note
that “inadequate traceability is an important contributing factor to
software project failures and budget overruns.” In his book Business
Rule Concepts, Ronald G. Ross makes a similar point (writing specifically
about business rule traceability, but the concept also applies to
requirements traceability): “Discovering or reconstructing the pedigree
(something from which it has been derived) of a business rule is time-
consuming, error-prone, and sometimes impossible. Worse, once
discovered or reproduced for a particular need . . . the history is often
not retained. That means the whole process must be repeated. Think of
rulebook management [or requirements traceability] as a practical
means to create pinpoint corporate memory, always keeping it right at
your fingertips.”
 It complies with established industry standards. Kannenberg and
Saiedian further point out that traceability is a key ingredient in many
respected industry standards for software development.
 If offers much easier impact analysis. Requirements traceability enables
intelligent impact analysis; if a stakeholder wants to change a
requirement once it is in development or testing, traceable links to
business needs and other requirements enable an analyst or project
manager to report the full impact of the requested change.
• In addition to these benefits, BABOK also notes that traceability helps
“to assist in scope and change management, risk management, time
management, cost management, and communication management.”
For all of these reasons, many experts agree that requirements
traceability is an essential practice for the business analyst.

Traceability Matrix
• A traceability matrix is a document, usually in the form of a table,
that helps correlate and trace business, application, security or any
other requirements to their implementation, testing or completion.
It evaluates and relates between different system components and
provides the status of project requirements in terms of their level of
completion.
• A traceability matrix is primarily used in software development
projects to trace, identify and verify that a specific functionality or
component is being developed.
• Typically, a traceability matrix is a worksheet type document
consisting of a table(s). Two different sets of values are compared
against each other by placing an identifier for one set in the top row,
and the other set on the left column. If there is commonality or a
relationship, a mark is placed where the column and row intersect.

Traceability Matrix
• For example, if software being developed is to be evaluated for
completion using a traceability matrix, project requirements can be
placed within the left column and their pertaining test cases on the
top row. If the project requirement and its test case are completed,
a mark can be placed where they intersect on the chart, and all of
these requirements can be added to calculate software completion
status.

Requirement Metrics
• Software requirements are the foundations from which quality is
measured. Measurement enables to improve the software process;
assist in planning, tracking and controlling the software project and
assess the quality of the software thus produced.
• Quality issues such as accuracy, security and performance are often
crucial to the success of a software system. Quality should be
maintained from starting phase of software development.
Requirements management, play an important role in maintaining
quality of software. A project should deliver the right solution on
time and within budget with proper requirements management.
Software quality can be maintained by checking quality attributes in
• Requirements metrics such as volatility, traceability, size and
completeness are used to measure requirements engineering phase
of software development lifecycle. Manual measurement is
expensive, time consuming and prone to error therefore automated
tools should be used. Automated requirements tools are helpful
in
measuring requirements metrics.
Requirement Metrics
• Tom DeMarco stated that “You cannot control what you cannot
measure”. Software metric are helpful in improving the quality
of software, planning the budget, its cost estimation etc.
• Peter Drucker also indicated that “If you can’t measure it, you
can’t manage it”. If a project manager and team members are
not able to precisely measure what they are going to do, then
it would not be possible for them to effectively manage and
improve the performance of a project. The success of a
software project is the primary goal.
• A software metric is a measurement derived from a software
product (the output), process, or resource (the input). Its
purpose is to provide a quantitative assessment of the extent
to which the product, process, or resource possesses certain
attributes.

Requirement Metrics
• The goals of software metrics are to identify and measure essential
factors which effects software development. However, organizations
face certain hindrances for metrics such as ill defined metrics,
misrepresentation of software life cycle, incompleteness of models,
weakness of measurement atomization and lack of metric validation.
• Metrics that can be gathered from requirements are
– the size of the requirements,
– requirements traceability,
– requirements completeness and
– requirements volatility.
• Size Metrics – Size is an important and general metrics used to
measure requirements. List of size is common metrics used to
measure size of software. Use Cases can also be considered as a size
measurement when they are used to describe requirements. For
example number of use cases, number of functions covered etc.
Requirement Metrics
• Requirements Traceability Metrics
• Traceability is the ability to trace requirements in a specification to
their origin from higher level to lower level requirements in a set of
documented links. Traceability provides information which helps in
determining whether all relationship and dependencies are
addressed. This also makes requirements leakage - existence of lower
level requirements with no valid origin from higher level visible. It
helps in preventing wrong interpretations of other metrics.
• Requirements Completeness Metrics
• Requirements Completeness Metrics are used to assess whether a
requirement is at wrong level of hierarchy or too complex.
• Requirements are considered as complete if all pages are numbered,
all figures and tables have captions and numbers, all references are
present, all sections and subsections are numbered and no TB to be
determine should be present see SRS for details.

Requirement Metrics
• Requirements Volatility Metrics
• The degree to which requirement changes over a time period is called
volatility of requirements. This metric is used to assess reasons for
change of requirements over a period of time. Requirements degree
of change is also checked by this metric.
• Volatility can be high in the initial phase of software development. It
should be reduced as the project progress so that further
development should not be affected.
 Objectives of Software Measurement
• Measurement is needed for assessing the status of products,
processes and resources. Every measurement activity must be in the
way of achieving clearly defined goals.
 Modeler and Norman, mention the following objectives of software
measurements.

Requirement Metrics
– Understanding- Measurement help to understand what is
happening during development and maintenance phases of
software development. Measurement should be done in order to
derive models of processes and examine relationships among the
process parameters. It leads to better understanding and
improved software projects.
– Early Problem Identification- Measurement, rather than waiting
problem to occur, allows early problem identification and
rectification as software management strategy. If problems are
detected earlier it saves resources of the organization.
– Planning/Estimation- Better project planning and estimation.
Amount of rework is a significant cause of failure for exceeding
the estimated budget. As the number of defects increases the
cost of fixing those errors also increases.
– Quality- The number and frequency of problems and defects are
inversely proportional to the software quality. This is one of the
direct measurements of the software product.
Requirement Metrics
– Schedule- The amount of workload, number of people and the
way processes are used are initial factors that contribute to the
preparation of schedule. Projects can be tracked on regular basis.
Increased development team productivity, measurement allows
to control what is happening on projects. Davis, claims if metrics
are not applied early in the software development, then the
number of errors will increase during later stages.
 Types of Metrics
• Metrics are categorized into products, process and resource metrics.
• Product Metrics- measure the software products at any stage of
software development. They can be applied from requirements
phase through installation. These metrics measures size of the
program, the number of pages of documents and complexity of
software design.

Requirement Metrics
• It can be list of criteria, duration of tests calculated in number of
hours, months and number of defects discovered. Size of the software
can be measured by its length, functionality and complexity. LOC is a
common criteria used to measure length of the software. It is the
physical size of the programs used to write code.
• Process Metrics
• Process metrics measure the process of software development. It
includes the type of methodology used, experience level of human
resources and overall development time. Overall development time of
the software product is an objective metrics. If given as a task this
should have same results from all the observers.
• Project/Resource Metrics
• Metrics collected from past projects are used as a basis from which
effort and time estimates are made for current software work. As a
project proceeds, measures of effort and calendar time expended are
compared to original estimates (and the project schedule). The project
manager uses these data to monitor and control progress.

Chapter 3-5: Requirements Engineering Task, Requirements Analysis, Requirements Specification

Uploaded by

Copyright:

Available Formats

You might also like

Chapter 3-5: Requirements Engineering Task, Requirements Analysis, Requirements Specification

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 3-5: Requirements Engineering Task, Requirements Analysis, Requirements Specification

Uploaded by

Copyright:

Available Formats

Chapter 3-5:

Requirements Engineering Task,

CT-3212: Chapter 3 - Requirement Engineering 2

CT-3212: Chapter 3 - Requirement Engineering 5

CT-3212: Chapter 3 - Requirement Engineering 7

CT-3212: Chapter 3 - Requirement Engineering 10

CT-3212: Chapter 3 - Requirement Engineering 15

CT-3212: Chapter 3 - Requirement Engineering 16

CT-3212: Chapter 3 - Requirement Engineering 17

CT-3212: Chapter 3 - Requirement Engineering 18

CT-3212: Chapter 3 - Requirement Engineering 19

CT-3212: Chapter 3 - Requirement Engineering 20

CT-3212: Chapter 3 - Requirement Engineering 21

requirements at this stage.

CT-3212: Chapter 3 - Requirement Engineering 24

CT-3212: Chapter 3 - Requirement Engineering 25

CT-3212: Chapter 3 - Requirement Engineering 28

CT-3212: Chapter 3 - Requirement Engineering 29

CT-3212: Chapter 5 - Requirements Specification 35

CT-3212: Chapter 3 - Requirement Engineering 36

CT-3212: Chapter 3 - Requirement Engineering 38

CT-3212: Chapter 3 - Requirement Engineering 39

CT-3212: Chapter 5 - Requirements Specification 43

CT-3212: Chapter 5 - Requirements Specification 45

CT-3212: Chapter 5 - Requirements Specification 46

CT-3212: Chapter 5 - Requirements Specification 47

CT-3212: Chapter 5 - Requirements Specification 48

CT-3212: Chapter 5 - Requirements Specification 49

CT-3212: Chapter 5 - Requirements Specification 52

CT-3212: Chapter 5 - Requirements Specification 53

CT-3212: Chapter 5 - Requirements Specification 54

CT-3212: Chapter 5 - Requirements Specification 57

CT-3212: Chapter 5 - Requirements Specification 59

CT-3212: Chapter 5 - Requirements Specification 60

CT-3212: Chapter 5 - Requirements Specification 62

You might also like