Home - Mastering Business Analysis - Introduction€¦ · Web viewTo enter information, click the...

©2011 ASPE SDLCwww.aspe-sdlc.com

<Project Name>

Software Requirements Specification

Version: 1.0

Date: ______________

Prepared by: ____________________________


Document Instructions

The project name is entered on the header where indicated by “<Project Name>”.

Areas where information is to be entered appear in darker gray shaded fields; these fields may be blank or may contain text instructions or samples. To enter information, click the gray field and begin typing; any instructional or sample text will be deleted when you begin typing.

Document UsageThis document is not a checklist and does not provide guidance on how to properly identify, gather, analyze, validate and verify requirements, and must not be used as such. It is solely for documenting the final outcome of the activities performed during the appropriate phase of the project.

Revision HistoryDate Version Author Section Change Summary

1.0 Initial draft



Table of Contents1. Introduction..........................................................................................................................4

1.1 Purpose..........................................................................................................................41.2 Scope.............................................................................................................................41.3 Definitions, Acronyms and Abbreviations......................................................................41.4 References.....................................................................................................................4

2. Functional Requirements....................................................................................................53. Business Rules....................................................................................................................64. Data Definitions (Business Objects)..................................................................................75. Use Cases.............................................................................................................................8

5.1 UC-1: <Use Case Name>..............................................................................................8

6. Non-Functional (System) Requirements.........................................................................106.1 Availability....................................................................................................................106.2 Efficiency (Performance)..............................................................................................106.3 Flexibility......................................................................................................................106.4 Integrity (Security)........................................................................................................106.5 Interoperability.............................................................................................................106.6 Reliability......................................................................................................................116.7 Robustness (Fault Tolerance)......................................................................................116.8 Usability.......................................................................................................................116.9 Maintainability..............................................................................................................116.10 Portability.................................................................................................................116.11 Reusability...............................................................................................................126.12 Testability.................................................................................................................126.13 External Interfaces...................................................................................................12

6.13.1 User Interfaces...............................................................................................126.13.2 Hardware Interfaces.......................................................................................126.13.3 Software Interfaces........................................................................................126.13.4 Communications Interfaces............................................................................12

6.14 Design Constraints...................................................................................................136.15 Miscellaneous Requirements...................................................................................13

6.15.1 Documentation Requirements........................................................................136.15.2 Purchased Components.................................................................................136.15.3 Safety Requirements......................................................................................136.15.4 Licensing and Security Requirements............................................................136.15.5 Legal, Copyright and Other Notices...............................................................146.15.6 Applicable Standards.....................................................................................146.15.7 Internationalization and Localization..............................................................146.15.8 Physical Deliverables.....................................................................................146.15.9 Installation and Deployment...........................................................................14

6.16 Supporting Information.............................................................................................146.16.1 Appendices....................................................................................................14



1. Introduction

1.1 PurposeState the purpose of the document (to collect all functional requirements not expressed in the process model, as well as non-functional requirements and design constraints). Specify the intended audience for the document.

1.2 ScopeIdentify the product(s) to be produced by name. Explain what the software product will and will not do. Describe the application of the software being specified, including relevant benefits, objectives, and goals.

Current System

Describe the current business system. Include a description of manual and automated processes. State why the system is being enhanced/replaced.

Desired System

Describe the desired system. Include a high-level description of any solution option(s) that may be known at this time.

1.3 Definitions, Acronyms and Abbreviations Provide the definitions of all terms, acronyms and abbreviations required to

properly interpret the SRS. This information may be provided by reference to one or more appendices in the SRS or by reference to other documents.

1.4 References Provide a complete list of all documents referenced elsewhere in the SRS.

Identify each document by title, report number (if applicable), date and publishing organization. Specify the sources from which the reference can be obtained.



2. Functional Requirements

Describe the functional requirements of the system for those requirements that are expressed in the natural language style or are otherwise not included in any models. Requirements may be organized by any means that makes sense to project stakeholders.



3. Business Rules

Describe the business rules of the system. Business rules may be organized by any means that makes sense to the project stakeholders.



4. Data Definitions (Business Objects)Repeat this definition for as many objects as are defined in the project scope.

Object Name Name the business object in singular and without regard to its implementation.

Description Briefly describe the business object, or re-use the definition from the glossary section.

Function(s)

List the CRUD functions to be performed on or with this data.

Data

List the data elements, attributes or characteristics of the object.

Rules

List the business rules (formulas, values, ranges, etc) and relational business rules associated with the object or its data elements.



5. Use CasesRepeat this section for as many use cases as are contained within the project’s scope.

5.1 UC-1: <Use Case Name>Scope: Indicate the scope of the use case.

Level: Indicate the level (summary, user goal, sub-function, etc.) of the use case.

Primary Actor: Indicate the actor that initiates the use case.

Stakeholders and Interests:Indicate all stakeholders and their interests.

Preconditions:List the preconditions (the state of the system prior to beginning the use case) of the use case.

Minimal Guarantees: Indicate the minimal guarantee (the state of the system even if the use case is not successful).

Success Guarantees: Indicate the success guarantees (the state of the system after successful completion of the use case; added to the minimal guarantee).

Trigger



Indicate the business event, performed by the primary actor, that begins the use case. (Optional: could be the first step of the use case narrative.)

UC-1: <Use Case Name> (continued)Main Success Scenario:

Describe, via numbered steps, the perfect-world, best-case scenario of the use case.

Extension Scenarios:Describe any alternative and/or exception scenarios of the use case (using whatever numbering scheme makes sense to the project stakeholders).



Technology and Data Variations:Describe any variations of the use case that may result from variations of technology and/or data used in the process.



6. Non-Functional RequirementsRequirements that express some of the “attributes of the system,” or “attributes of the system environment.” They are not necessarily related to a specific business function or functional requirement, but instead, the behavior of the system as a whole.

6.1 AvailabilityState when the system should be available to its users. Indicate the business case for anything that seems "extreme" (i.e. 24/7/365). Include scheduled maintenance periods. Indicate how much down time would be tolererable by users.

6.2 Efficiency (Performance)State the performance characteristics of the system, expressed quantitatively where possible and related to a specific business process where applicable.

6.3 FlexibilitySpecify the need to extend, augment, or expand the system, especially if the system is to be developed in phases.

6.4 Integrity (Security)Indicate requirements for blocking unauthorized access to system functions, preventing information loss, ensuring that the software is protected from virus, and protecting the privacy and safety of data entered into the system.

6.5 InteroperabilityIndicate requirements to exchange data with other systems. List which other applications users will employ in conjunction with this one and what data they plan to exchange.



6.6 ReliabilitySpecify how long the software should execute without failure. Assess the impact of system failure and list requirements for minimizing and/or recovering from such failure.

6.7 Robustness (Fault Tolerance)Indicate requirements that specify how the system should behave when confronted with invalid input, defects in connected software/hardware components, or unexpected operating conditions. Indicate, in general, how error conditions should be handled.

6.8 UsabilityList requirements associated with "user-friendliness"; consider individual users and user classes, their capabilities and knowledge.

6.9 MaintainabilityDescribe requireuremts associated with correction of defects or modifications to the software. Critical for systems that undergo frequent update.

6.10 PortabilitySpecify the need to migrate the software to another platform or operating environment, now or in the future.



6.11 ReusabilityIndicate the need to re-use components of the software within this system or in another system.

6.12 TestabilitySpecify requirements for verifying and/or testing the software. May be expressed as cyclomatic complexity, the measure of the number of logic branches in the source code (more branches and loops makes the module harder to test).

6.13 External Interfaces

6.13.1 User InterfacesThe logical characteristics of each interface between the software and its users, e.g. screen formats, page/window layouts, content of any reports, menus or queries, programmable function keys, etc.) necessary to accomplish the requirements.

6.13.2 Hardware InterfacesSpecify the logical characteristics of each interface between the software and the hardware components of the system, including configuration characteristics. List the devices to be supported, how they will be supported, and protocols.

6.13.3 Software InterfacesSpecify the use of other required software products and interfaces with other application systems. Include the name, mnemonic, specification and/or version number and source of the other software.



6.13.4 Communications InterfacesSpecify the various interfaces to communications such as local area network protocols, etc.



6.14 Design ConstraintsRestrictions on the design of a system, or the process by which a system is developed, that do not affect the external behavior of the system but that must be fulfilled to meet technical, business, or contractual obligations.

6.15 Miscellaneous Requirements

6.15.1 Documentation RequirementsRequirements for user, administrator and/or system documentation.

6.15.2 Purchased ComponentsList the purchased components used with the system, licensing or usage restrictions, and compatibility/interoperability requirements.

6.15.3 Safety RequirementsSpecify requirements that are concerned with possible loss, damage, or harm that could result from the use of the product. Define safeguards or action to be taken. Identify certifications, policies or regulations to which the product must conform.

6.15.4 Licensing and Security RequirementsDescribe the licensing and usage enforcement requirements or other restrictions for usage, security and accessibility.



3.15 Miscellaneous Requirements (continued)

6.15.5 Legal, Copyright and Other NoticesState any required legal disclaimers, warranties, copyright notices, patent notices, trademarks or logo compliance issues.

6.15.6 Applicable StandardsReference any applicable standards and the specific sections of any such standards that apply.

6.15.7 Internationalization and LocalizationState any requirements for support and application of different user languages, dialects, character sets, time zones, work days, hours, holidays, etc.

6.15.8 Physical DeliverablesDefine any specific deliverable artifacts required by the user or the customer.

6.15.9 Installation and DeploymentDescribe any specific configuration or target system preparation required to support installation and/or deployment of the system.



6.16 Supporting Information

6.16.1 AppendicesThe appendices are not always considered part of an actual SRS and are not always necessary.


Home - Mastering Business Analysis - Introduction€¦ · Web viewTo enter information, click the...

Documents

Transcript of Home - Mastering Business Analysis - Introduction€¦ · Web viewTo enter information, click the...