Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

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

The importance of organizing requirements information and the components of a vision document. It also covers the process of organizing requirements for complex hardware and software systems. a template for a software product and describes feature attributes that will be used to evaluate, track, prioritize, and manage the features. It also lists the product features and exemplary use cases.

Typology: Slides

2021/2022

Available from 08/18/2022

SamenKhan
SamenKhan 🇵🇰

231 documents

Partial preview of the text

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

Organizing Requirements Information 4  (^) Whether expressed as user needs, a list of features, a set of use cases, or another format , requirements must be captured and documented.  (^) System requirements are the assembled configuration that a system must have in order for a hardware or software application to run smoothly and efficiently  (^) 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.  (^) More likely, developers and users are mutually exclusive , and many stakeholders are involved in software development.  (^) Realities of budgets and schedules.

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

9

 During any process of requirements elicitation, More/Detailed requirements

will arise.

 It may not be appropriate to include such requirements in the current

requirements set to avoid confusion for current release.

 On the other hand, it's unwise to discard extra req because

 Future Req may be added in next release.

 It rep value added work products.

 It is recom to record both req but more emphasis on current req.

Future Requirements

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

12

 The Vision document is important because it captures the product from all

significant perspectives in a short, abstract, readable, and manageable form.

 It is primarily focused investment made in the process of gathering Vision

document information will pay handsome returns in later phases.

 Write the Vision document in plain language to make understandable for

concerned SH.

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.

 (^) You may also wish to schedule a further requirements workshop or other elicitation process to features to include in Version 2. 0 and some new future features too.  (^) Some of these features will already be obvious, (Customer feedback + Experiencing the product) The Vision Document of 15 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.

18  (^) 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 what 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.

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

Template for a Software Product Vision Docume nt 20

Template for a Software Product VisionDocume nt 21

Template for a Software Product VisionDocume nt 22

Template for a Software Product VisionDocume nt 23

Assignment 2

Each Student required to build product vision document having attributes/subattributes About

the product mentioned earlier

You can use any template of your choice or make newly attractive template but that must covers

all headings/subheading as mentioned.

Each students will try utmost to use different product for making vision document

Plagiarize Content will be marked zero.

Submission.. 06/06/2022 Tentatively

Reference

s

24 1 .

  1. Managing Software Requirements: A Use Case Approach, Second Edition By Dean Leffingwell, Don Widrig, Addison- Wesley
  2. Multiple Search Engines like google, yahoo, study.com, etc.