www.themegallery.com logo chapter 10 documenting the requirements 120070069

www.themegallery.com

LOGO

Chapter 10

Documenting the Requirements

Chapter 10

Documenting the Requirements

POWERED BY : ABDULLAH M. ABU NADA 120070069

OUR GROUP

our groupMohammed AL-AzaizaMohammed AL-Azaiza

Nael Wael SkaikNael Wael Skaik

Hammed MusallamHammed Musallam

Mohammed Al-KahloutMohammed Al-Kahlout

Abdullah Abu NadaAbdullah Abu Nada

Husain ShaalanHusain Shaalan

Contents

The Software Requirements Specification

Requirements Specification Template

Guidelines for Writing Requirements

Sample Requirements, Before and After

The Data Dictionary

Chapter10

Overview

The result of requirements development is a documented agreement between customers and developers about the product to be built. As we saw in earlier chapters, the vision and scope document contains the business requirements, and the user requirements often are captured in the form of use cases. The product's detailed functional and nonfunctional requirements reside in a software requirements specification (SRS). Unless you write all these requirements in an organized and readable fashion and have key project stakeholders review them, people will not be sure what they're agreeing to.

We can represent software requirements in several ways:

Documents

Graphical models

Formal specifications

that use well-structured and carefully written natural language

that define requirements using mathematically precise formal logic languages

that illustrate transformational processes, system states and changes between them, data relationships, logic flows, or object classes and their relationships


The software requirements specification is sometimes called a functional specification, a product specification, a requirements document, or a system specification, although organizations do not use these terms in the same way. The SRS precisely states the functions and capabilities that a software system must provide and the constraints that it must respect. The SRS is the basis for all subsequent project planning, design, and coding, as well as the foundation for system testing and user documentation. It should describe as completely as necessary the system's behaviors under various conditions. It should not contain design, construction, testing, or project management details other than known design and implementation constraints.

Several audiences rely on the SRS:

Customers, the marketing department, and sales staff need to know what product they can expect to be delivered.

Project managers base their estimates of schedule, effort, and resources on the product description.

The SRS tells the software development team what to build.

The testing group uses the SRS to develop test plans, cases, and procedures.

The SRS tells maintenance and support staff what each part of the product is supposed to do.

Documentation writers base user manuals and help screens on the SRS and the user interface design.

Several audiences rely on the SRS:

Training personnel use the SRS and user documentation to develop educational materials.

Legal staff ensure that the requirements comply with applicable laws and regulations.

Subcontractors base their work on, and can be legally held to, the SRS.


As the ultimate repository for the product requirements, the SRS must be comprehensive. Developers and customers should make no assumptions. If any desired capability or quality doesn't appear somewhere in the requirements agreement, no one should expect it to appear in the product.

You don't have to write the SRS for the entire product before beginning development, but you do need to capture the requirements for each increment before building that increment. Incremental development is appropriate when the stakeholders cannot identify all the requirements at the outset and if it's imperative to get some functionality into the users' hands quickly. However, every project should baseline an agreement for each set of requirements before the team implements them. Base lining is the process of transitioning an SRS under development into one that has been reviewed and approved. Working from the same set of requirements minimizes miscommunication and unnecessary rework.

requirements readability suggestions

The Essential Software Requirement," presented several characteristics of high-quality requirements statements and specifications. Keep the following requirements readability suggestions in mind:

• Label sections

Label sections, subsections, and individual requirements consistently.

• Leave text

Leave text ragged on the right margin, rather than fully justified.

• Use visual emphasis

such as bold, underline, italics, and different fonts) consistently and judiciously.

• Create a table of contents

and perhaps an index to help readers find the information they need.

requirements readability suggestions

• Number all figures and tables

give them captions, and refer to them by number.

• Use your word processor's

cross-reference facility rather than hard-coded page or section numbers to refer to other locations within a document.

• Use hyperlinks

to let the reader jump to related sections in the SRS or in other documents.

• Use an appropriate template

Use an appropriate template to organize all the necessary information.

• Use white space liberally.

Labeling Requirements


Sequence Number

Hierarchical Textual Tags Hierarchical Textual Tags

• Labeling Requiremen

tsHierarchical NumberingHierarchical Numbering


To satisfy the quality criteria of traceability and modifiability.

every functional requirement must beuniquely and persistently identified.

This allows you to refer to specific requirements in a change request

modification history, cross-reference, or requirements traceability matrix.


1-Sequence Number

1-The simplest approach gives every requirement a unique sequence number .EX-Commercial requirements management tools assign such an identifier when a user adds a new requirement to the tool's database. (The tools also support hierarchical numbering.) The prefix indicates the requirement type, such as UR for user requirement2-A number is not reused if a requirement is deleted. 3-This simple numbering approach doesn't provide any logical or hierarchical grouping of related requirements, and the labels give no clues as to what each requirement is about.

several requirements-labeling methods and technique makes the most sense for your situation




2-Hierarchical Numbering

1-In the most commonly used convention, if the functional requirements appear in section 3.2 of your SRS, they will all have labels that begin with 3.2 (for example, 3.2.4.3). More digits indicate a more detailed, lower-level requirement.2-This method is simple and compact.3- Your word processor can assign the numbers automatically. However, the labels can grow to many digits in even a medium-sized SRS. In addition, numeric labels tell you nothing about the purpose of each requirement.More seriously, this scheme does not generate persistent labels. 3-If you insert a new requirement, the numbers of all following requirements in that section will be incremented


2-Hierarchical Numbering

4-Delete or move a requirement, and the numbers following it in that section will be decremented. 5-These changes disrupt any references to those requirements elsewhere in the system


Click to edit title style

3-Hierarchical Textual Tags

Consultant tom gilp suggests atext-bsed hierarchical tagging scheme for labeling individual requirements.

Consider this requirement: "The system shall ask the user to confirm any request to print more than 10 copies." This requirement might be tagged Print.ConfirmCopies.

This indicates that it is part of the print function and relates to the number of copies to print.

Hierarchical textual tags are structured, meaningful, and unaffected by adding, deleting, or moving other requirements



1.Introduction•The introduction presents an overview to help the reader understand how the SRS is organized and how to use it.

1.1 Purpose•Identify the product whose software requirements are specified in this document, including the revision or release number.•Describe the scope of the product that is covered by this SRS, particularly if this SRS describes only part of the system or a single subsystem.

1.2 Document Conventions•Describe any standards or typographical conventions that were followed when writing this SRS, such as fonts or highlighting that have special significance.


1.3 Intended Audience and Reading Suggestions•Describe the different types of reader that the document is intended for.• Audience such as :•Developers.• project managers. •marketing staff. •users.•testers.•documentation writers. •Describe what the rest of this SRS contains and how it is organized.

1.4 Project Scope•Provide a short description of the software being specified and its purpose, including relevant benefits, objectives, and goals.•Refer to the vision and scope document if its avaliable.


1.5 references•List any other documents or Web addresses to which this SRS refers.•These may include :•User interface style guides.• Contracts.•Standards. •System requirements specifications.•Use case documents.•A vision and scope document.

•Provide enough information so that the reader could access a copy of each reference.

2. Overall Descriptions•This section presents a high-level overview of the product and the environment

•2.1 Product Perspective•Describe the context and origin of the product being specified in this SRS.•State how this software relates to the overall system and identify major interfaces between the two.

•2.2 Product Features•Summarize the major features of the product or the significant functions that it performs or lets the user perform. •Details will be provided in Section 3.• Organize the functions to make them understandable to any reader of the SRS. •A picture of the major groups of related requirements and how they relate, such as

• data flow diagram • a class diagram.


•2.3 User Classes and Characteristics•Identify the various user classes that you anticipate will use this product.•Describe the pertinent characteristics of each user class. Certain requirements may pertain only to certain user classes. Distinguish the favored user classes from those who are less important to satisfy.

•2.4 Operating Environment•Describe the environment in which the software will operate, including the hardware, operating system and versions, and any other software components or applications .


•2.5 User Documentation•List the user documentation components that will be delivered along with the software.•This May Include •user manuals.•on-line help.•Tutorials.•Identify any known user documentation delivery formats or standards.


•2.6 Design and Implementation Constraints•Describe any items or issues that will limit the options available to the developers. •These might include:•hardware limitations such as timing requirements, memory requirements.•Existing user interfaces conventions. •Specific technologies, tools, and databases to be used.•Restrictions on the product's operating environment.•Required development conventions or standards.•Limitations imposed by business rules.•Compatibility with earlier products.•Standard data interchange formats such as XML.


•2.7 Assumptions and Dependencies•List any assumed factors that could affect the requirements stated in the SRS.• These could include issues around the development or operating environment, or constraints.• The project could be affected if these assumptions are incorrect, are not shared, or change. •identify any dependencies the project has on external factors, such as the release date of the next version, unless they are already documented elsewhere.


3.System features

•The template is organized by system feature, which is just one possible way to arrange the functional requirements. •Other organizational options include by use case, mode of operation, user class, stimulus, response, object class, or functional hierarchy (IEEE 1998b),or combinations of these elements.•You should select an organizational approach that makes it easy for readers to understand the product's intended capabilities.•State the name of the feature in just a few words, such as "Spell Check" .•Description and Priority:

1. Provide a short description of the feature and indicate whether it is of high, medium, or low priority.

2. Priorities are dynamic, changing over the course of the project .


3. System features CON.

•Stimulus/Response Sequences:

system responses of input stimuli (user actions, signals from external devices, or other triggers) that define the behaviors for this feature.

•Functional Requirements:

Itemize the detailed functional requirements associated with this feature. These are the software capabilities that must be present for the user to carry out the feature's services or to perform a use case.

Describe how the product should respond to anticipated error conditions and to invalid inputs and actions.


4 External Interface Requirements

•This section provides information to ensure that the system will communicate properly with external components.•Reaching agreement on external and internal system interfaces has been identified as a software industry best practice (Brown 1996).

•Divided into:1.User Interfaces.2.Hardware Interfaces.3.Software Interfaces.Communications Interfaces


4.1. User Interfaces:

Describe the logical characteristics of each user interface that the system needs. Some possible items to include are:

1.References to GUI standards .2.Standards for fonts, icons, button labels, images, color schemes, field tabbing sequences.3.Screen layout or resolution constraints.4.Standard buttons, functions, or navigation links that will appear on every screen, such as a help button.5.Shortcut keys.6.Message display conventions.7.Layout standards to facilitate software localization.8.Accommodations for visually impaired users.


4.2. Hardware Interfaces:

Describe the logical and physical characteristics of each interface between the software product and the hardware components of the system. This may include the supported device types, the nature of the data and control interactions between the software and the hardware, and communication protocols to be used .

4.3. Software Interfaces:

•Describe the connections between this product and other specific software components (name and version), including databases, operating systems, tools, libraries, and integrated commercial components.•Describe the services needed and the nature of communications.• Identify the data items or messages coming into the system and going out and describe the purpose of each.


4.4. Communications Interfaces:

•Describe the requirements associated with any communications functions required by this product.•including e-mail, web browser, network server communications protocols, electronic forms, and so on.• Identify any communication standards that will be used, such as FTP or HTTP. •Specify any communication security issues, data transfer rates, and synchronization mechanisms.


5 Other Nonfuncdtional Requirements•This section specifies nonfunctional requirements other than external interface requirements.

•5.1 Performance Requirements.•If there are performance requirements for the product under various System operations, state them here and explain their causes, to help the developers understand the intent and make suitable design choices. •Specify the timing relationships for real time systems. Make such requirements as specific as possible. •We may need to state performance requirements for individual functional requirements or features.


5.2 Safety Requirements.• Safty and security are examples of Quality Attributes.•Specify those requirements that are concerned with possible loss, damage, or harm that could result from the use of the product. •Define any safeguards or actions that must be taken, as well as actions that must be prevented. •Refer to any external policies that state safety issues that affect the product’s design or use.

•5.3 Security Requirements.•Specify any requirements regarding security or privacy issues surrounding use of the product or protection of the data used or created by the product. •Define any user identity authentication requirements. •Refer to any external policies or regulations containing security issues that affect the product. •Define any security or privacy certifications that must be satisfied.


5.4 Software Quality Attributes• Specify any additional quality characteristics for the product that will be

important to either the customers or the developers. •Some to consider are: 1.adaptability. 2. Availability. 3. Correctness.4. Flexibility. 5.Interoperability . 6.Maintainability.

•Write these to be specific, quantitative, and verifiable when possible.

6 Other Requirements•Define any other requirements not covered elsewhere in the SRS. •This might include :•database requirements • legal requirements•reuse objectives for the project.


Appendix A: Glossary•Define all the terms necessary to properly interpret the SRS, including abbreviations.

Appendix B: Analysis Models•Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams, state-transition diagrams, or entity-relationship diagrams.

Appendix C: Issues List•This is a dynamic list of the open requirements issues that remain to be resolved.

www.themegallery.com

LOGO

Thank youThank you

120070069POWERED BY : ABDULLAH M. ABU NADA 120070069