Requirement documentation

Requirements Documentation
◼ Many people involved in a typical system
▪ Users, developers, analysts, testers, Architect, etc.
◼ All parties must reach agreement about what system is
being built
◼ It unlikely that all user needs are going to be satisfied in
any particular release
Requirements Documentation
◼ Inevitable communication problems inherent in a multiple-
person effort demand that a written document be produced
to which all parties can agree and refer
◼ Documents that define the product to be built are typically
called a requirements specification
▪ The requirements specification for a system or application
describes the external behavior of that system
Why So Many Document ??
Requirements can rarely be defined in a single monolithic document due to
due following reasons:
◼ The system may be very complex.
◼ The customers' needs are being documented prior to documenting
detailed requirements.
◼ The system may be a member of a family of related products.
◼ The system being constructed satisfies only a subset of all the
requirements identified.
◼ Marketing and business goals need to be separated from the detailed
product requirements.
 WHY SO MANY DOCUMENTS
In any of these cases, you will need to maintain multiple documents
and, of course, to consider a number of special cases.
 One "parent" document defines requirements for the overall "system," including
hardware, software, people, and procedures. Another defines requirements for
just the software piece
 One document defines the features of the system in general terms, and another
defines requirements in more specific terms.
 One document defines the full set of requirements for a family of products, and
another defines requirements for just one specific application and for one
specific release
 One document describes the overall business requirements and business
environment in which the product will reside and another defines the external
behavior of the system being built
Documents
◼System requirements specification
▪ Defines requirements for the overall "system,"
including hardware, software, people, and procedures
◼Vision document
▪ defines the features of the system in general terms
◼Product family requirements or Product family
Vision document
▪ defines the full set of requirements for a family of
products
◼Business requirements document, or marketing
requirements document
▪ Describes the overall business requirements and
business environment in which the product will reside
Software Requirements
Specification
◼Software Requirements Specification
▪ SRS for short
▪ defines requirements in specific terms but for just
the software piece
▪ defines the external behavior of the system being
built
▪ defines requirements for just one specific
application and for one specific release or a
specific release of a specific application within the
family
ORGANIZING REQUIREMENTS (A SYSTEM OF SYSTEM)
In these cases, a system-level requirements
specification is created that describes the external
behavior of the system, such as fuel capacity,
without knowledge of or reference to any of its
subsystems

once the requirements for the system are agreed

on, a systems engineering activity is performed.

Systems engineering refines a system into

subsystems, describing the detailed interfaces
among the subsystems, and allocating each of the
system-level requirements to one or more
subsystems.

Next, a requirements specification is developed

for each subsystem. These specifications should
describe the external behavior of the subsystem
completely, without reference to any of its
subsystems
specifications that are themselves refined into
additional subsystem specifications are termed
system requirements specifications, or system-
level requirements specifications

The lowest-level specifications, that is,

those that are not further decomposed, usually
correspond to software-only or
hardware-only subsystems and are termed
software requirements specifications
or hardware requirements specifications,
respectively
 Product Family
◼ Develop a product-family
vision document that
describes the ways in which
the products are intended
to work together and the
other features that could be
shared.
◼ To better understand the
shared-usage model, you
might also develop a set of
use cases showing how the
users will interact with
various applications running
together.
 Product Family
◼ Develop a common
software requirements
specification that defines
the specific requirements
for shared functionality,
such as menu structures
and communication
protocols.
◼ For each product in the
family, develop a Vision
document, software
requirements
specification, and a use-
case model that defines its
specific functionality
Business and Marketing
Requirements
◼ Product is developed by a technical world but marketed and
used in business world.
◼ We must consider factors such as among market windows,
target markets, product packaging, distribution channels,
functionality, marketing costs, resource availability, margins,
ability to pay back over large numbers of copies sold, and so
on
◼ These requirements are captured in Marketing Requirements
Document (MRD)
◼ These requirements are not part of the requirements
specifications.
MRD
◼ Who is the customer?
◼ Who is the user?
◼ What markets do we intend to sell to?
◼ How are these markets segmented?
◼ Are the requirements of the users in these segments different?
◼ What classes of users exist?
◼ What need does the product satisfy?
◼ What kind of product is it?
◼ What is the product's key benefits; why should someone buy it?
◼ Who is the competition?
◼ What differentiates the product from the competition?
◼ In what environment will the system he used?
◼ What will the development cost be?
◼ At what price do you want to sell the product?
◼ How will the product be installed, distributed, and maintained?
VISION DOCUMENT
 Vision Document
 Combines into a single document abstract of both
▪ a marketing requirements document and
▪ a product requirements document
 We want to develop this particular document further, for two
reasons.
 Every project needs a Vision document.
 It will help us demonstrate the requirements process further
Vision Document
◼ Describes the application in general terms, including
descriptions of the target market, the users of the system,
and the features of the application

◼ The single most important document in a software project,

captures the needs of the user, the features of the system,
and other common requirements for the project.
 vision document
For a software product, the Vision document also serves as the basis for
discussion and agreement among the three primary internal stakeholder
communities of the project:

1. The marketing department, which serves as the proxy for the customer and
the user, and which will ultimately be held accountable for the success of the
product after release

2. The project team developing the application

3. The management team, which will be held responsible for the business
outcome of the endeavor
 vision document(introduction)
• Purpose: State the purpose of this vision document.

• Scope: Briefly describe the scope of this vision document, including which

programs, projects, applications, and business processes the document is
associated with. Include anything else that this document affects or influences.

• References: List all documents that the vision document refers to. Identify each
document by title, report number (if applicable), date, and publishing
organization. Specify the sources from which readers can obtain the references;
the sources are ideally available in RM or in other online repositories.

• Overview: Describe the vision-document contents and explain how the

document is organized.
 Vision document (positioning)
• Business opportunity: Briefly describe the business opportunity that
is addressed by this project.
• Problem statement: Summarize the problem that this project solves.
Use the following statements as a model
The problem of (describe the problem) affects (the stakeholders affected by the
problem). The impact of the problem is (what is the impact of the problem). A
successful solution would include (list some key benefits of a successful
solution).

• Product position statement: Provide an overall statement that

summarizes at the highest level the unique position the product
intends to take in the marketplace. Use the following statements as a
model, providing project details
 Vision document (positioning)
• Product position statement: 
• For the (target customer), who (statement of the need or
opportunity). The (product name) is a (product category) that
(statement of key benefit, that is, the compelling reason to
buy). Unlike (primary competitive alternative), our product
(statement of primary differentiation).
 vision document(Stakeholder and user descriptions)

This section provides a profile of the stakeholders and users who

are involved in the project.
This section also identifies the key problems that stakeholders
and users consider that the proposed solution must address.
 vision document(Stakeholder and user descriptions)

1. Market demographics: 
Summarize the key market demographics that motivate your
product decisions.
Estimate the market size and growth by using the number of
potential users.
Alternatively, estimate the amount of money that your
customers spend
Answer these strategic questions:
 What is the reputation of your organization in these markets?
• What would you like the reputation to be?
• How does this product or service support your goals?
 vision document(Stakeholder and user descriptions)

2. Stakeholder summary:
 List all the identified stakeholders. For each stakeholder type,
provide this information:
• Name: Name the stakeholder type.
• Role: Briefly describe the role this stakeholder type plays in the
development effort.

3. User summary: 
 List all the identified user types. For each user type, provide this
information :
• Name: Name the user type
• Description: Briefly describe the relationship of this type of user to
the system under development.
• Stakeholder: List which stakeholder type represents this user type.
 vision document(Stakeholder and user descriptions)
4. User environment: Detail the working environment of the
target user. Here are some suggestions:
• How many people are involved in completing the task? Is this
changing?
• How long is a task cycle? How much time do users spend in
each activity? Is this changing?
• What unique environmental constraints affect the project?
For example, do users require mobile devices, work outdoors,
or work during flights?
• Which system platforms are in use today? Are there future
platforms planned?
• What other applications are in use? Does your application
need to integrate with them?
 vision document(Stakeholder and user descriptions)
5. Stakeholder profiles: Describe each stakeholder in the project
by completing the following table for each stakeholder. 

• Representative: State who represents the stakeholder to the

project i.e. Enter the representatives' names.
• Responsibilities: List the key responsibilities of the
stakeholder on the system under development
• Success criteria: State how the stakeholder defines success.
How is the stakeholder rewarded?
• Deliverables: Identify additional deliverables that the
stakeholder requires. These items might be project
deliverables or output from the system under development.
 vision document(Stakeholder and user descriptions)
5. Stakeholder profiles: Describe each stakeholder in the project
by completing the following table for each stakeholder. 

• Involvement - Describe how the stakeholder is involved in the

project. Where possible, relate the involvement to the
process roles; for example, a stakeholder might be a
requirements reviewer.
• Comments or issues: State problems that interfere with
success and any other relevant information.
 vision document(Stakeholder and user descriptions)
• User profiles: Describe each user of the system
• Remember user types can be experts and novices
• for example, an expert might need a sophisticated, flexible
tool with cross-platform support, while a novice might need a
tool that is easy to use.
Vision document (product overview)
 Vision document (product overview)

Customer benefit Supporting features

New support staff can quickly learn A knowledge base assists support
how to use the product. personnel in quickly identifying known
fixes
Management can identify problem Trend and distribution reports enable a
areas and gauge staff workload. high-level review of problem status.
Distributed support teams can With a replication server, current
work together to solve problems. database information can be shared
throughout the enterprise.
Customers can help themselves, A knowledge base can be made available
lowering support costs and over the Internet. The knowledge base
improving response time. includes hypertext search capabilities
and a graphical query engine.
Vision document (product features)
Vision document(product features)
Vision document(product requirements)
Product Position Statement
Product Position Statement
Product position statement example
 Stakeholder profiles
Representative John Whitewood, IT Department Head
Description Approval Authority
Type Understands the college's financial status, and the long term vision of
the Board Of Governors.
Responsibilities Represents the IT Department and the Board Of Governors. 
Monitor's project status, and has authority over budget approval. 
Ensures that the project meets short term and long term goals of the
college. Plans for potential re-sale opportunities, and long term
maintenance of the system.

Success Criteria Success is completion of the project within approved budget, and a
demonstrated reduction in registrar workload (and therefore reduced
cost for the projected future). 
There must also be a general perception by the Board of Governors
that the project meets user needs. The system should be easily
modified for use by other colleges, for potential re-sale opportunities.
The stakeholder is rewarded by receiving recognition by the Board of
Governors.

Involvement Management reviewer, Budgetary approval signatory, Involved in

staff performance reviews.
Deliverables None.
Stakeholder summary
User summary
 Key stakeholders or user needs
Need Priority Concerns Current Solution Proposed
Solutions
Student  High  Student  Currently students must complete a  Students would
Course Course course registration form and submit it like to have
 
Registratio Registration is to the Registrar. The Registrar takes up online access to
n slow and to 2 weeks to process the form and quickly determine
inefficient. another week to send the confirmation course availability
back to the student. At this point, any and assigned
schedule changes due to full courses professors.
or student preference require the entire
three week process to be repeated.
This provides students limited
flexibility in selecting their schedule
of courses.
Early Medium Long delay to The final report cards are typically Online access to
access to get grades, mailed out to the students 8 weeks individual course
Student continuous after the start of the examination grades was a
Grades queries to period. During this time, students recommendation
professors. continually phone their professors in from most
attempts to find out their marks sooner students
completing the
survey.