Embed Size (px)
Citation preview
SOFTWARE REQUIREMENTS ENGINEERING
LECTURE # 8
DEFINING THE SYSTEM
1
Engr. Ali Javed 19th June, 2013
Instructor Information 2
Course Instructor: Engr. Ali Javed
Assistant Professor
Department of Software Engineering
U.E.T Taxila
Email: [email protected]
Website: http://web.uettaxila.edu.pk/uet/UETsub/perSites/[email protected]
Contact No: +92-51-9047747
Office hours:
Monday, 09:00 - 11:00, Office # 7 S.E.D
Lab Instructor: Engr. Asra, Engr. Sobia
Engr. Ali Javed
• Organizing Requirements Information
• Future Requirements
• Vision Document
• Components of Vision Document
• Delta Vision Document
• Vision Document Template
Presentation Outline 3
Engr. Ali Javed
Organizing Requirements Information
Whether expressed as user needs, a list of features, a set of use cases, or another format, requirements
must be captured and documented.
If you were the only developer as well as maintainer or user of the system, you might consider designing
and coding it immediately after identifying your needs.
However, few system developments have such simplicity. More likely, developers and users are mutually
exclusive, and many stakeholders are involved in software development. All parties must reach agreement
about what system is being built.
Realities of budgets and schedules make it unlikely that all user needs are going to be satisfied in any
particular release.
Engr. Ali Javed
4
Unavoidable communication problems among the stakeholders
demand that requirements be captured in a way that they can
be reviewed and approved and to which all parties can agree.
You will need to maintain requirements organized into multiple
requirements sets, each set reflecting the requirements for a
particular system, a subsystem, or a number of subsystems together,
as in the examples below.
One / set defines the features of the system in general terms, and another
defines requirements in more specific terms. Often, the former is called the
Vision document, whereas the latter is called the Software Requirements
Specification
One "parent" document defines requirements for the overall
"system,“ including hardware, software, people, and procedures, and
another defines requirements for just the software piece. Often the
former document is called a System Requirements Specification, whereas
the latter is known as Software Requirements Specification
Organizing Requirements Information
Engr. Ali Javed
5
One set defines the full set of requirements for a family of products, and is
called Product family requirements document or Product family vision document
One set describes the overall business requirements and business environment in which the
product will belong to, this document is called business requirements document
Organizing Requirements Information
Engr. Ali Javed
6
Some systems are sufficiently complex that the only reasonable way to visualize and
to build them is as a system of subsystems, which in turn are visualized as systems of
subsystems, containing hardware as well as software components, depicted in Figure 1
In these cases, a system-level requirements set is created that describes the system, as
well as the system-level use cases that describe functional behavior of the system.
Organizing Requirements of Complex Hardware
& Software Systems
Figure 1:: A system of subsystems Engr. Ali Javed
7
Next, requirements are developed for each subsystem. These should describe the external behavior of the
subsystem completely, without reference to any of its subsystems , as shown in Figure 2.
Organizing Requirements of Complex Hardware
& Software Systems
Figure 2:: Hierarchy of requirements resulting from system design
Engr. Ali Javed
8
During any process of requirements elicitation, requirements will arise that are considered
appropriate for the next release of the product.
It may not be appropriate to include such requirements in the requirements set since
we cannot afford to create any confusion about what requirements are and are not to
be implemented in a particular release.
On the other hand, it's unwise to discard them because they represent value-added work
products, and we will want to collect requirements from them for future releases, So it makes
sense to record both types of requirements but to clearly identify those requirements that are
planned for the current release.
Future Requirements
Engr. Ali Javed
9
The Vision document describes the application in general terms, including descriptions of
the target market, the system users, and the application features.
Vision document, even if short or perhaps incomplete, helps assure that everyone working on
the project is working toward a single objective. The team has common goals, Otherwise, the
team will work toward unknown or conflicting objectives, and chaos will likely result.
Over the years, it has evolved to become a standard best practice for use when defining a
software application.
The Vision Document
Engr. Ali Javed
10
The Vision document captures the needs of the user, the features of the system, and
other common requirements for the project. As such, the scope of the Vision document
extends over the top two levels of the requirements pyramid, thereby defining at a high level
of abstraction both the problem and the solution.
Components of Vision Document
Engr. Ali Javed
11
The Vision document is important because it captures the product from all significant
perspectives in a short, abstract, readable, and manageable form.
As such, the Vision document is the primary focus in the early phases of the project,
and any investment made in the process of gathering Vision document information will pay
handsome returns in later phases.
Write the Vision document in plain language and at a level of detail that makes it easy for
the primary stakeholders of the project to review and understand the document.
Components of Vision Document
Engr. Ali Javed
12
The Vision document must contain at least the following:
General and introductory information
A description of the users of the system and the markets served
Features intended for release in version 1.0
Other requirements
Future features that have been elicited but will not be incorporated in the 1.0 release
The Vision Document of Version 1.0
Engr. Ali Javed
13
As the project evolves, features become better defined.
New features will be discovered and added to the document.
As you approach version 2.0, you certainly want to maintain the document that has served you so well.
The logical next step in the evolution of the project and this document is to include the future features that
were included in v1.0 of the document but not implemented and to schedule them for v2.0.
The Vision Document of Version 2.0
Engr. Ali Javed
14
You may also wish to schedule a further requirements workshop or other elicitation process to discover new
features to include in Version 2.0 and some new future features too.
Some of these features will already be obvious, based on customer feedback; others will come from the
experience of the team.
In any case, record these newly discovered features in v2.0 of the Vision document, either as scheduled
for inclusion in 2.0 or as new future features.
The Vision Document of Version 2.0
Engr. Ali Javed
15
You will probably discover that some of the features implemented in version
1.0 did not deliver the intended value, perhaps because
the external environment changed during the process and the feature was no longer
needed or
will be replaced by a new feature or
perhaps because the customers simply didn't need the feature as they thought they
would.
In any case, you may discover that you will need to remove some features in
the next release.
How do you record these "anti-requirements"? Simply use the Vision document
to record the fact that the particular feature must be removed in the next
release.
The Vision Document of Version 2.0
Engr. Ali Javed
16
The Vision Document of Version 2.0
17
As the team works, it will discover that the document grows and becomes more difficult to read and
understand over time because it is now much longer and contains much information that has not changed
since the previous release.
Therefore, we suggest the construction of the Delta Vision document. The Delta Vision document focuses on
only two things: what has changed and any other information that must be included for context.
Engr. Ali Javed
The result is a Delta Vision document that now focuses primarily on what is new and what is different
about this release.
Vision 1.0 is our comprehensive starting point, telling us what we need to know at the start of our project.
Delta Vision 2.0 defines that which is different in this release.
Taken together, Vision 1.0 plus Delta Vision 2.0 constitute the whole product definition.
The Vision Document of Version 2.0
Engr. Ali Javed
18
The Vision Document of Version 2.0
Figure 3: The Evolving Product Definition
Engr. Ali Javed
19
Template for a Software Product Vision
Document
Engr. Ali Javed
20
Template for a Software Product Vision
Document
Engr. Ali Javed
21
Template for a Software Product Vision
Document
Engr. Ali Javed
22
Template for a Software Product Vision
Document
Engr. Ali Javed
23
References 24
1. Managing Software Requirements: A Use Case Approach, Second Edition By
Dean Leffingwell, Don Widrig, Addison- Wesley
Engr. Ali Javed
For any query Feel Free to ask 25
Engr. Ali Javed
