Software Requirements Analysis ITSE 311 Chapter 10 SRS

ﺗﺤﻠﻴﻞ ﻣﺘﻄﻠﺒﺎﺕ ﺍﻟﺒﺮﻣﺠﻴﺎﺕ Software Requirements Analysis ITSE 311 Chapter 10 SRS Documents ﺣﻨﺎﻥ ﺍﻟﺪﺍﻗﻴﺰ. ﺩ h. dagez@uot. edu. ly

The software requirements document The requirements document is a formal document used to communicate the requirements to customers, engineers and managers It is also known as software requirements specifications or SRS 2

The software requirements document -1 The services and functions which the system should provide. The constraints under which the system must operate. Definitions of other systems which the system must integrate with. Information about the application domain of the system, e. g. , how to carry out particular types of computation Constraints on the process used to develop the system. 3

The software requirements document -2 A glossary should also be included to document technical terms due to multiple stakeholders will read the documents and they need to understand the meanings of different terms. Also because stakeholders have different educational backgrounds 4

Software Requirements Specification The SRS document is useful in: statement of user needs contract document reference document definition for implementation 5

SRS Document The SRS document is known as black-box specification: the system is considered as a black box whose internal details are not known. only its visible external (i. e. input/output) behaviour is documented. Input Data S Output Data 6

Examples of Bad SRS Documents Unstructured Specifications: Narrative essay ( )ﻣﻘﺎﻝ ﺳﺮﺩﻱ --- one of the worst types of specification document: Difficult to change, difficult to be detailed, difficult to be unambiguous, scope for contradictions, etc. 7

Examples of Bad SRS Documents Noise: Presence of text containing information irrelevant to the problem. Silence: Important features to proper solution of the problem are omitted. 8

Examples of Bad SRS Documents Overspecification: Addressing “how to” features For example, “Library member names should be stored in a sorted descending order” Overspecification restricts the solution space for the designer. Contradictions: Contradictions might arise if the same thing described at several places in different ways. 9

Users of Requirements Documents - 1 System customers Specify the requirements and read them to check that they meet their needs. They specify changes to the requirements Project managers Use the requirements document to plan for the system and to plan the system development process 10

Users of Requirements Documents - 2 System engineers Use the requirements to understand what system is to be developed System test engineers Use the requirements to develop validation tests for the system System maintenance engineers Use the requirements to help understand the system and the relationships between its parts 11

Users of Requirements Documents 12

Requirements specification RS Requirements specification is the process of writing down the user and system requirements in a requirements document. Ideally, the user and system requirements should be clear, unambiguous, easy to understand, complete, and consistent. In practice, this is difficult to achieve as stakeholders interpret the requirements in different ways and there are often inherent conflicts and inconsistencies in the requirements. 13

User Requirements in Requirement Document Ideally, should specify only the external behavior of the system. The requirements document should not include details of the system architecture or design. Should not use software jargon, structured notations, or formal notations. Should write user requirements in natural language, with simple tables, and forms. 14

User and System Requirements language User requirements are almost always written in natural language supplemented by appropriate diagrams and tables in the requirements document. System requirements may also be written in natural language but other notations based on forms, graphical system models, or mathematical system models can also be used. 15

Possible notations for writing user and system requirements 16

To minimize misunderstandings when writing natural language requirements, 1. 2. 3. Invent a standard format and ensure that all requirement definitions follow to that format. Use language consistently to distinguish between needed and desirable requirements. The needed requirements are requirements that the system must support and are usually written using ‘shall’. Desirable requirements are not essential and are written using ‘should’. Use text highlighting (bold, italic, or color) to pick out key parts of the requirement. 17

Structured specifications Structured natural language is a way of writing system requirements where the freedom of the requirements writer is limited and all requirements are written in a standard way. Structured language notations use templates to specify system requirements. The specification may use programming language constructs to show alternatives and iteration, and may highlight key elements using shading or different fonts. 18

What Should Be Included in SRS? Functional requirements They define what the system does. These describe all the inputs and outputs to and from the system as well as information concerning how the inputs and outputs interrelate. Non-functional requirements They define the attributes of a system as it performs its job. They include system’s required levels of efficiency, reliability, security, maintainability, portability, visibility, capacity, and standards compliance Some of these are quality attributes of a software product . 19

What Should Not Be Included in SRS? Project requirements (for example, staffing, schedules, costs, milestones, activities, phases, reporting procedures) Designs Product assurance plans (for example, configuration management plans, verification and validation plans, test plans, quality assurance plans) 20

SRS Quality Attributes Correct Unambiguous Complete Verifiable Consistent Understandable by customer Modifiable Traceable Design independent 21

Correct An SRS is correct if and only if every requirement stated therein represents something required of the system to be built Unambiguous An SRS is unambiguous if and only if every requirement stated therein has only one interpretation At a minimum all terms with multiple meanings must appear in a glossary All natural languages invite ambiguity 22

Complete An SRS is complete if it possesses the following four qualities Everything that the software is supposed to do is included in the SRS Definitions of the responses of the software to all realizable classes of input data in all realizable classes of situations is included All pages are numbered; all figures and tables are numbered, named, and referenced; all terms and units of measure are provided; and all referenced material and sections are present No sections are marked “To Be Determined” (TBD). 23

Verifiable An SRS is verifiable if and only if every requirement stated therein is verifiable. A requirement is verifiable if and only if there exists some finite cost effective process with which a person or machine can check that the actual as-built software product meets the requirement 24

Consistent An SRS is consistent if and only if: No requirement stated therein is in conflict with other preceding documents, such as specification or a statement of work No subset of individual requirements stated therein conflict. Conflicts can be any of the following Conflicting behavior Conflicting terms Conflicting characteristics Temporal inconsistency 25

Understandable by Customers Primary readers of SRS in many cases are customers or users, who tend to be experts in an application area but are not necessarily trained in computer science Modifiable Ø An SRS is modifiable if its structure and style are such that any necessary changes to the requirements can be made easily, completely, and consistently Ø Existence of index, table of contents, cross-referencing, and appropriate pagenumbering. Traced An SRS is traced if the origin of its requirements is clear. That means that the SRS includes references to earlier supportive documents 26

27

1. Introduction The introduction of the SRS should provide an overview of the entire SRS. It should contain the following subsections: a) Purpose; b) Scope; c) Definitions and abbreviations; d) References; e) Overview.

1. 1 Purpose This subsection should a) Define the purpose of the SRS; b) Specify the intended audience for the SRS.

1. 2 Scope This subsection should a) Identify the software product(s) to be produced by name. b) Explains what the software product(s) will, and, if necessary, will not do; c) Describe the application of the software being specified, including relevant benefits, objectives, and goals; d) Be dependable with similar statements in higher-level specifications (e. g. , the system requirements specification), if they exist.

1. 3 Definitions and abbreviations This subsection should provide the definitions of all terms and abbreviations required to properly interpret the SRS. This information may be provided by reference to one or more appendixes in the SRS or by reference to other documents.

1. 4 References This subsection should a) Provide a complete list of all documents referenced elsewhere in the SRS; b) Identify each document by title, report number (if applicable), date, and publishing organization; c) Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.

1. 5 Overview This subsection should a) Describe what the rest of the SRS contains; b) Explain how the SRS is organized.

2. Overall description (Section 2 of the SRS) This section of the SRS should describe the general factors that affect the product and its requirements. This section does not state specific requirements. Instead, it provides a background for those requirements, which are defined in detail in Section 3 of the SRS, and makes them easier to understand. This section usually consists of six subsections, as follows: a) Product perspective; b) Product functions; c) User characteristics; d) Constraints; e) Assumptions and dependencies; f) Assigning of requirements.

2. 1 Product perspective A block diagram showing the major components of the larger system, interconnections, and external interfaces can be helpful. This subsection should also describe how the software operates inside various constraints. For example, these constraints could include: a) System interfaces; b) User interfaces; c) Hardware interfaces; d) Software interfaces; e) Communications interfaces; f) Memory; g) Operations; h) Site adaptation requirements.

3. 0 Specific requirements (Section 3 of the SRS) This section of the SRS should contain all of the software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements. Throughout this section, every stated requirement should be externally perceivable by users, operators, or other external systems. These requirements should include at a minimum a description of every input into the system, every output from the system, and all functions performed by the system in response to an input or in support of an output. As this is often the largest and most important part of the SRS, the following principles apply: a) Specific requirements should be stated in conformance with all the characteristics described in 4. 3. b) Specific requirements should be cross-referenced to earlier documents that relate. c) All requirements should be uniquely identifiable. d) Careful attention should be given to organizing the requirements to maximize readability.

Any Question ? Thanks