The

Practices
Of Specification Document

Welcome EveryOne
 01 02 03
Discuss OutLine Explain
Practices Of Practices To Analysis Practices Of
Requirement Requirement Requirement
Elicitation Specifications
 04 05 06
List At Least List At Least Discuss
3 Good Practices To 5 Good Practices To Why Important To
Validate Project Management Train Customer
Requirement Related To Requirement About Requirement
Engineering
 07
Discuss
The Importance To Educate The Business Analyst Their
Businesses Domain
 WHOA!
My Name Is Najib Abd Elwahed I’m
Student At Limu With ID “3736” And I
gonna Talk About The Practices Of
Requirement
 “The hardest part of the
software task is arriving at a
complete and consistent
specification, and much of the
essence of building a program is
in fact the debugging of the
specification.”
—Fred Brooks
 Discuss
01 Practices Of Requirement
Elicitation
 Practices Of Requirement Elicitation

● Define Product Vision And Project Scope :

The vision and scope document contains the product’s business
requirements. The vision statement gives all stakeholders a common
understanding of the product’s outcome.

● Identify user classes And Their Characteristics :

To avoid overlooking the needs of any user community, identify the various
groups of users for your product. They might differ in frequency of use,
features used, privilege levels, or experience.

● Select A Product Champion For Each User Class :

Identify an individual who can accurately serve as the literal voice of the
customer for each user class. The product champion presents the needs of
the user class and makes decisions on its behalf.
 Con’t

• Conduct focus groups with typical users :

Convene groups of representative users of your previous products or of similar products. Collect their
input on both functionality and quality characteristics for the product under development.

• Work with user representatives to identify user requirements :

Explore with your user representatives the tasks they need to accomplish with the software and the
value they’re trying to achieve.

• Identify system events and responses :

List the external events that the system can experience and its expected response to each event.
There are three classes of external events.

• Hold elicitation interviews :

Interviews can be performed one-on-one or with a small group of stakeholders. They are an effective
way to elicit requirements without taking too much stakeholder time because you meet with people to
discuss only the specific requirements that are important to them.
 Con’t

• Hold facilitated elicitation workshops :

Facilitated requirements-elicitation workshops that permit collaboration between analysts and customers
are a powerful way to explore user needs and to draft requirements documents.

• Observe users performing their jobs :

Watching users perform their business tasks establishes a context for their potential use of a new
application. Simple process flow diagrams can depict the steps and decisions involved and show how
different user groups interact.

• Distribute questionnaires :
Questionnaires are a way to survey large groups of users to determine what they need. Questionnaires are
useful with any large user population but are particularly helpful with distributed groups.
 Con’t
● Perform document analysis :
Existing documentation can help reveal how systems currently work
or what they are supposed to do. Documentation includes any written
information about current
systems, business processes, requirements specifications, competitor
research, and COTS (commercial
off-the-shelf) package user manuals.

● Examine problem reports of current systems for

requirement ideas :
Problem reports and enhancement requests from users provide a rich
source of ideas for capabilities to include in a later release or in a new
product.
● Reuse existing requirements :
If customers request functionality similar to that already present in an
existing product, see whether the requirements (and the customers!) are
flexible enough to permit reusing or adapting the existing software
components.
 Outline
02 Practices To Analysis
Requirement
 Practices To Analysis Requirement
● Model the application environment :
The context diagram is a simple analysis model that shows how the new
system fits into its environment. It defines the boundaries and interfaces
between the system being developed and external entities, such as users,
hardware devices, and other systems.

● Create user interface and technical prototypes :

When developers or users aren’t certain about the requirements, construct
a prototype—a partial, possible, or preliminary implementation—to make
the concepts and possibilities more tangible. Prototypes allow developers
and users to achieve a mutual understanding of the problem being solved,
as well as helping to validate requirements.

● Analyze requirement feasibility :

The BA should work with developers to evaluate the feasibility of
implementing each requirement at acceptable cost and performance in the
intended operating environment. This allows stakeholders to understand the
risks associated with implementing each requirement, including conflicts
and dependencies with other requirements, dependencies on external
factors, and technical obstacles.
 Con’t
● Prioritize the requirements :
It’s important to prioritize requirements to ensure that the team implements
the highest value or most timely functionality first. Apply an analytical
approach to determine the relative implementation priority of product
features, use cases, user stories, or functional requirements. Based on
priority, determine which release or increment will contain each feature or
set of requirements.

● Create a data dictionary :

Definitions of the data items and structures associated with the system
reside in the data dictionary. This enables everyone working on the project
to use consistent data definitions. As requirements are developed, the data
dictionary should define data items from the problem domain to facilitate
communication between the customers and the development team.

● Model the requirements :

An analysis model is a diagram that depicts requirements visually, in
contrast to the textual representation of a list of functional requirements.
Models can reveal incorrect, inconsistent, missing, and superfluous
requirements.
 Con’t

● Analyze interfaces between your system and the outside

world :
All software systems have connections to other parts of the world through
external interfaces. Information systems have user interfaces and often exchange
data with other software systems. Embedded systems involve interconnections
between software and hardware components.

● Allocate requirements to subsystems :

The requirements for a complex product that contains multiple subsystems must
be apportioned among the various software, hardware, and human subsystems
and components. An example of such a product is an access system to a secure
building that includes magnetic or optical badges, scanners, video cameras and
recorders, door locks, and human guards.
 Explain
03 Practices Of Requirement
Specifications
 Practices Of Requirement Specifications

● Adopt requirement document templates :

Adopt standard templates for documenting requirements in your
organization, such as the vision and scope, The templates provide a
consistent structure for recording various groups of requirements-related
information. Even if you don’t store the requirements in traditional
document form, the template will remind you of the various kinds of
requirements information to explore and record.

● Identify requirement origins :

To ensure that all stakeholders know why every requirement is needed,
trace each one back to its origin, This might be a use case or some other
customer input, a high-level system requirement, or a business rule.
 Con’t

• Uniquely label each requirement :

Define a convention for giving each requirement a unique identifying label. The convention must be
robust enough to withstand additions, deletions, and changes made in the requirements over time.

• Record business rules :

Business rules include corporate policies, government regulations, standards, and computational
algorithms. Document your business rules separately from a project’s requirements because they
typically have an existence beyond the scope of a specific project.

• Specify nonfunctional requirements :

It’s possible to implement a solution that does exactly what it’s supposed to do but does not satisfy the
users’ quality expectations. To avoid that problem, you need to go beyond the functionality discussion
to understand the quality characteristics that are important to success. These characteristics include
performance, reliability, usability, modifiability, and many others.
 List At Least
04 3 Good Practices To Validate
Requirement
Good Practices To Validate Requirement

● Review the requirements :

Peer review of requirements, particularly the type of rigorous review called
inspection, is one of the highest-value software quality practices available
Assemble a small team of reviewers who represent different perspectives
(such as analyst, customer, developer, and tester), and carefully examine
the written requirements, analysis models, and related information for
defects.

● Test the requirements :

Tests constitute an alternative view of the requirements. Writing tests
requires you to think about how to tell if the expected functionality was
correctly implemented. Derive tests from the user requirements to
document the expected behavior of the product under specified conditions.
 Con’t

● Define acceptance criteria :

Ask users to describe how they will determine whether the solution meets
their needs and is fit for use. Acceptance criteria include a combination of
the software passing a defined set of acceptance tests based on user
requirements, demonstrating satisfaction of specific nonfunctional
requirements, tracking open defects and issues, having infrastructure and
training in place for a successful rollout.

● Simulate the requirements :

Commercial tools are available that allow a project team to simulate a
proposed system either in place of or to augment written requirements
specifications. Simulation takes prototyping to the next level, by letting Bas
work with users to rapidly build executable mock-ups of a system. Users can
interact with the simulated system to validate requirements and make
design choices, making the requirements come to life before they are cast
into the concrete of code. Simulation is not a substitute for thoughtful
requirements elicitation and analysis, but it does provide a powerful
supplement.
 List At Least
05 5 Good Practices To Project Management
Related To Requirement Engineering
 Good Practices To Project Management
● Establish a requirements change control process :
Rather than stifling change or hoping changes don’t happen, accept the fact
that they will and establish a mechanism to prevent rampant changes from
causing chaos. Your change process should define how requirements changes
are proposed, analyzed, and resolved. Manage all proposed changes through
this process. Defect-tracking tools can support the change control process.

● Perform impact analysis on requirements changes :

Impact analysis is an important element of the change process that helps the
CCB make informed business decisions. Evaluate each proposed requirement
change to assess the effect it will have on the project.

● Establish baselines and control versions of requirements

sets :
A baseline defines a set of agreed-upon requirements, typically for a specific
release or iteration. After the requirements have been baselined, changes
should be made only through the project’s change control process. Give every
version of the requirements specification a unique identifier to avoid
confusion between drafts and baselines and between previous and current
versions.
 Con’t
● Maintain a history of requirements changes :
Retain a history of the changes made to individual requirements.
Sometimes you need to revert to an earlier version of a requirement or want
to know how a requirement came to be in its current form. Record the dates
that requirements were changed, the changes that were made, who made
each change, and why. A version control tool or requirements management
tool can help with these tasks.

● Track the status of each requirement :

Establish a repository with one record for each discrete requirement of any
type that affects implementation. Store key attributes about each
requirement, including its status (such as proposed, approved,
implemented, or verified), so you can monitor the number of requirements
in each status category at any time.

● Track requirements issues :

When busy people are working on a complex project, it’s easy to lose sight
of the many issues that arise, including questions about requirements that
need resolution, gaps to eradicate, and issues arising from requirements
reviews. Issue-tracking tools can keep these items from falling through the
cracks.
 Con’t

● Maintain a requirements traceability matrix :

It’s often valuable—and sometimes required—to assemble a set of links that
connect each functional requirement to the design and code elements that
implement it and the tests that verify it. Such a requirements traceability matrix
is helpful for confirming that all requirements are implemented and verified. It’s
also useful during maintenance when a requirement has to be modified.

● Use a requirements management tool :

Commercial requirements management tools let you store various types of
requirements in a database. Such tools help you implement and automate many
of the other requirements management practices described in this section.
 Discuss
06 Practicesa Of Requirement
Specifications
Practices Of Requirement Specifications

● Review the requirements :

Peer review of requirements, particularly the type of rigorous review called
inspection, is one of the highest-value software quality practices available
Assemble a small team of reviewers who represent different perspectives
(such as analyst, customer, developer, and tester), and carefully examine
the written requirements, analysis models, and related information for
defects.

● Test the requirements :

Tests constitute an alternative view of the requirements. Writing tests
requires you to think about how to tell if the expected functionality was
correctly implemented. Derive tests from the user requirements to
document the expected behavior of the product under specified conditions.
 Explain
07 Practices Of Requirement
Specifications
Practices Of Requirement Specifications

● Review the requirements :

Peer review of requirements, particularly the type of rigorous review called
inspection, is one of the highest-value software quality practices available
Assemble a small team of reviewers who represent different perspectives
(such as analyst, customer, developer, and tester), and carefully examine
the written requirements, analysis models, and related information for
defects.

● Test the requirements :

Tests constitute an alternative view of the requirements. Writing tests
requires you to think about how to tell if the expected functionality was
correctly implemented. Derive tests from the user requirements to
document the expected behavior of the product under specified conditions.
 THANKS!
Do you have any questions?

CREDITS: This presentation template was

created by Slidesgo, including icons by Flaticon,
and infographics & images by Freepik.