Software Requirements Engineering Lecture #8 Defining the System, Slides of Software Engineering

Download Software Requirements Engineering Lecture #8 Defining the System and more Slides Software Engineering in PDF only on Docsity!

SOFTWARE REQUIREMENTS

ENGINEERING

LECTURE

DEFINING THE

SYSTEM

• (^) Organizing Requirements Information
• (^) Future Requirements
• (^) Vision Document
• (^) Components of Vision Document
• (^) Delta Vision Document
• (^) Vision Document Template

Presentation

Outline

5  (^) Unavoidable communication problems among the stakeholders demand.  (^) You will need to maintain requirements organized into multiple requirements sets,.  (^) 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 document defines requirements for the overall  (^) One "parent" "system,“ including hardware, software, people, and another defines procedures,requirements and for just the software piece. Often the former document is called a Vision Document , whereas the latter is known as Software Requirements Specification Organizing Requirements Information

6

 One set defines the full set of requirements for a family of

products called Product family vision document. (Vision)

 One set describes the overall business requirements and business environment in which the product

will belong to, this document is called business requirements document (Mission)

Organizing Requirements Information

 Some systems are sufficiently complex that the only reasonable way to visualize and to build

them is as a system of subsystems ,, containing hardware as well as software components, depicted in

below given pic.

 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

8  (^) Next, requirements are developed for each subsystem. These should describe the independent functionality 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

A system is a construct or collection of different elements that together produce results not obtainable by the elements alone. A subsystem is a single, predefined operating environment through which the system coordinates the work flow and resource use

10

 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 (Though not recomm), helps assure that everyone

working on the project toward a single objective. (Avoid conflicting objective)

 Over the years, it has evolved to become a standard best practice for use when defining a software

application.

The Vision Document

11

 The Vision document captures the needs of the user, the features of the system,

specifi cati on of Soft ware , and other related requirements for the project.

 As such, the scope of the Vision document covers top layers other then prob and sol domain.

Components of Vision Document

13

The Vision document must contain at least the following:

 General and introductory information (Background)

 A description of the users of the system and the markets served

 Features intended for release in version 1.

 Other requirements

 Future features that have been elicited but will not be incorporated in

the 1.0 release

The Vision Document of Version 1.

14  (^) 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 set compatible with V. 1.0 also. The Vision Document of Version 2.

16  (^) You will probably discover that some of the features implemented in version 1.0 did not deliver the intended value, perhaps because  (^) the changed external environment  (^) will be replaced by a new feature or  (^) customers simply didn't need the feature as they thought they would.  (^) In any case, you may discover that you will need to remove/add some features in the next release.  (^) How do you record these "anti-requirements"? The Vision Document of Version 2.

The Vision Document of 17 Version 2.  (^) 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 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  (^) other information that must be included as new context.

The Vision Document of Version 2. Figure 3: The Evolving Product 19

Template for a Software Product Vision Docume nt 20