Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
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
1 / 26
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
Organizing Requirements Information
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.
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
Future Requirements
10
The Vision Document
11
Components of Vision Document
12
Components of Vision Document
13
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
24 1 .