Software Requirements Analysis and Specification Requirements 1 Background

Software Requirements Analysis and Specification Requirements 1

Background n n n Problem of scale is a key issue for SE For small scale, understand specifying requirements is easy For large problem - very hard; probably the hardest, most problematic and error prone Input : user needs in minds of people Output : precise statement of what the future system will do Requirements 2

Background. . n n n Identifying and specifying req necessarily involves people interaction Cannot be automated Requirement (IEEE)= A condition or capability that must be possessed by a system Req. phase ends with a software requirements specification (SRS) document SRS specifies what the proposed system should do Requirements 3

Background. . n Requirements understanding is hard n n n Visualizing a future system is difficult Capability of the future system not clear, hence needs not clear Requirements change with time … Essential to do a proper analysis and specification of requirements Requirements 4

Need for SRS n SRS establishes basis of agreement between the user and the supplier. n n n Users needs have to be satisfied, but user may not understand software Developers will develop the system, but may not know about problem domain SRS is the medium to bridge the commn. gap and specify user needs in a manner both can understand Requirements 5

Need for SRS… n Helps user understand his needs. n n n users do not always know their needs must analyze and understand the potential the goal is not just to automate a manual system, but also to add value through IT The req process helps clarify needs SRS provides a reference for validation of the final product n n Clear understanding about what is expected. Validation - “ SW satisfies the SRS “ Requirements 6

Need for SRS… n High quality SRS essential for high Quality SW n n n Requirement errors get manifested in final sw to satisfy the quality objective, must begin with high quality SRS Requirements defects are not few n n 25% of all defects in one case; 54% of all defects found after UT. 80 defects in A 7 that resulted in change requests. Requirements 7

Need for SRS… n Good SRS reduces the development cost n n n SRS errors are expensive to fix later Req. changes can cost a lot (up to 40%) Good SRS can minimize changes and errors Substantial savings; extra effort spent during req. saves multiple times that effort An Example n Cost of fixing errors in req. , design , coding , acceptance testing and operation are 2 , 5 , 15 , 50 , 150 person-hours. Requirements 8

Requirements 9

Phase Cost(p-h) of fixing error Percenta ge of error detected No. of errors Cost per phase Design Coding Testing Operation Total Cost= person-hours Requirements 10

Phase Cost(p-h) of fixing error Percentage of error detected No. of errors Cost per phase Design 5 65% 50*65% = 32. 5 *5 Coding 15 2% 50*2%= 1 1*15 Testing 50 30% 50*30%= 15 15*50 Operation 150 3% 50*3%= 1. 5*150 Total Cost= 32. 5 *5 + 1*15 + 15*50 + 1. 5*150 = 1152 person-hours Requirements 11

Need for SRS… n Example … n n After req. phase 65% req errs detected in design , 2% in coding, 30% in Acceptance testing, 3% during operation If 50 requirement errors are not removed in the req. phase, the total cost 32. 5 *5 + 1*15 + 15*50 + 1. 5*150 = 1152 hrs If 100 person-hours invested additionally in req to catch these 50 defects , then development cost could be reduced by 1152 person-hours. Net reduction in cost is 1052 person-hours. Requirements 12

Requirements Process n n n Sequence of steps that need to be performed to convert user needs into SRS Process has to elicit needs and requirements and clearly specifies it Basic activities n n problem or requirement analysis requirement specification validation Analysis involves elicitation and is the hardest Requirements 13

Requirements Process. . needs Analysis Specification Validation Requirements 14

Requirement process. . n n Process is not linear, it is iterative and parallel Overlap between phases - some parts may be analyzed and specified Specification itself may help analysis Validation can show gaps that can lead to further analysis and spec Requirements 15

Requirements Process… n n Focus of analysis is on understanding the desired systems and it’s requirements Divide and conquer is the basic strategy n n Large volumes of information is generated n n decompose into small parts, understand each part and relation between parts organizing them is a key Techniques like data flow diagrams, object diagrams etc. used in the analysis Requirements 16

Requirements Process. . n Transition from analysis to specs is hard n n n in specs, external behavior specified during analysis, structure and domain are understood analysis structures helps in specification, but the transition is not final methods of analysis are similar to that of design, but objective and scope different analysis deals with the problem domain, whereas design deals with solution domain Requirements 17

Problem Analysis n n Aim: to gain an understanding of the needs, requirements, and constraints on the software Analysis involves n n n interviewing client and users reading manuals studying current systems helping client/users understand new possibilities Like becoming a consultant Must understand the working of the organization , client and users Requirements 18

Problem Analysis… n Some issues n n n Obtaining the necessary information Brainstorming: interacting with clients to establish desired properties Information organization, as large amount of info. gets collected Ensuring completeness Ensuring consistency Avoiding internal design Requirements 19

Problem Analysis… n n n Interpersonal issues are important Communication skills are very important Basic principle: problem partition Projection - get different views Will discuss few different analysis techniques Requirements 20

Characteristics of an SRS n What should be the characteristics of a good SRS? Some key ones are n n n Correct. Complete. Unambiguous. Consistent. Verifiable. Ranked for importance and/or stability. Requirements 21

Characteristics… n Correctness n n Completeness n n Each requirement accurately represents some desired feature in the final system All desired features/characteristics specified Hardest to satisfy Completeness and correctness strongly related Unambiguous n n n Each req. has exactly one meaning Without this, errors will creep in. Important as natural languages often used Requirements 22

Characteristics… n Verifiability n n n if every stated requirement is verifiable. There must exist a cost effective way of checking if s. w satisfies requirements Consistent n If there is no requirement that conflicts with another. two requirements don’t contradict each other Example: suppose a requirement(1) states that: event e is to occur before event f. But requirement(2) states that: event f should occur before event e. n Requirements 23

Characteristics… n Ranked for importance/stability n n n Needed for prioritizing in construction To reduce risks due to changing requirements Stability of a requirement reflects the chances of it changing in the future. Requirements 24

n Completeness, is the most important and difficult property to establish: n Missing requirements necessitate additions and modifications to the requirements later in the development cycle. n n Will increase cost. Incompleteness is also a major source of disagreement between the client and the supplier. Requirements 25

Components of an SRS n What should an SRS contain ? n n Having guidelines helps Clarifying this will help ensure completeness An SRS must specify requirements on n n Functionality Performance Design constraints External interfaces Requirements 26

Functional Requirements n n n Heart of the SRS document; this forms the bulk of the specs. Specifies all the functionality that the system should support (expected behavior of the system). Outputs for the given inputs and the relationship between them. All operations the system is to do. Must specify behavior for invalid inputs : n range of valid inputs must be specified. 27

Performance Requirements n n n All the performance constraints on the software system Two types of performance requirements: static and dynamic. Static: do not impose constraint on the execution. n number of terminals, number of simultaneous users, number of files. . called capacity requirements. Dynamic: specify constraints on the execution behavior. n n Generally on response time , throughput etc. Must be in measurable terms (verifiability): “response time should be good” not acceptable, response time for x should be less than one second 90% of the time. 28

Design Constraints n n n Factors in the client environment that restrict the choices standards that must be followed, resource limits, operating environment, reliability, security requirements, and policies Some such restrictions n Standard compliance and compatibility with other systems: (report format, accounting procedures) n n n Hardware Limitations: (the type of machines, operating system, languages supported, limits on primary/secondary storage. ) Reliability, fault tolerance, backup req. they make the system more complex and expensive. Security place restrictions on the use of certain 29 commands, control access…

External Interface n n n All interactions of the software with people, hardware, and sw User interface most important. A preliminary user manual should be created: (all user commands, …) General requirements of: “the system should be user friendly” should be avoided and use : “commands should be no longer than six characters” These should also be verifiable Requirements 30

Specification Language n n Language should support desired char of the SRS Formal languages are precise and unambiguous but hard Natural languages mostly used, with some structure for the document Formal languages used for special features or in highly critical systems Requirements 31

Structure of an SRS n Introduction n n Purpose , the basic objective of the system Scope of what the system is to do , not to do Overview Overall description n n Product perspective Product functions User characteristics Assumptions Constraints Requirements 32

Structure of an SRS… n Specific requirements n n n Acceptable criteria n n External interfaces Functional requirements Performance requirements Design constraints desirable to specify this up front. This standardization of the SRS was done by IEEE. Requirements 33

Other Approaches to Analysis Requirements 34

The Data Flow Model Every computer-based system is an information transform. . input computer based system 35 output CS 451 - Lecture 6

Data Flow Modeling n n Widely used; focuses on functions performed in the system Views a system as a network of data transforms through which the data flows Uses data flow diagrams (DFDs) and functional decomposition in modeling The SSAD methodology uses DFD to organize information, and guide analysis Requirements 36

Data flow diagrams n A DFD shows flow of data through the system n n Views system as transforming inputs to outputs Transformation done through transforms DFD captures how transformation occurs from input to output as data moves through the transforms Not limited to software Requirements 37

Data flow diagrams… n DFD n n n Transforms represented by named circles/bubbles Bubbles connected by arrows on which named data travels A rectangle represents a source or sink and is originator/consumer of data (often outside the system) Requirements 38

Data Flow Modeling Notation source or sink process data flow data store 39 CS 451 - Lecture 6

DFD Example Requirements 40

DFD Conventions n n n External files shown as labeled straight lines Need for multiple data flows by a process represented by * (means and) OR relationship represented by + All processes and arrows should be named Processes should represent transforms, arrows should represent some data Requirements 41

Data flow diagrams… n n n Focus on what transforms happen , how they are done is not important Usually major inputs/outputs shown, minor are ignored in this modeling No loops , conditional thinking , … DFD is NOT a control chart(flow chart), no algorithmic design/thinking Sink/Source , external files Requirements 42

Drawing a DFD n n n n n If get stuck , reverse direction If control logic comes in , stop and restart Label each arrows and bubbles Make use of + & * Try drawing alternate DFDs Leveled DFDs : DFD of a system may be very large Can organize it hierarchically Start with a top level DFD with a few bubbles then draw DFD for each bubble Preserve I/O when “ exploding”. Requirements 43

Drawing a DFD for a system n n Identify inputs, outputs, sources, sinks for the system Work your way consistently from inputs to outputs, and identify a few high-level transforms to capture full transformation If get stuck, reverse direction When high-level transforms defined, then refine each transform with more detailed transformations Requirements 44

Drawing a DFD for a system. . n n Never show control logic; if thinking in terms of loops/decisions, stop & restart Label each arrows and bubbles; carefully identify inputs and outputs of each transform Make use of + & * Try drawing alternate DFDs Requirements 45

Leveled DFDs n n n DFD of a system may be very large Can organize it hierarchically Start with a top level DFD with a few bubbles then draw DFD for each bubble Preserve I/O when “ exploding” a bubble so consistency preserved Makes drawing the leveled DFD a top-down refinement process, and allows modeling of large and complex systems Requirements 46

DFD drawing – common errors n n n n n Unlabeled data flows Missing data flows Extraneous data flows Consistency not maintained during refinement Missing processes Too detailed or too abstract Contains some control information Black Hole. Miracle. Requirements 47

Requirements Validation n n The basic objective of the requirements validation activity is to ensure that the SRS reflects the actual requirements accurately and clearly. and to check that SRS document is of good quality. Lot of room for misunderstanding Errors possible Expensive to fix req. defects later Must try to remove most errors in SRS Requirements 48

common errors n Most common errors n n n Omission Inconsistency Incorrect fact Ambiguity clerical errors - 30% 10 -30% 5 -20% Requirements 49

Omission n some user requirement is simply not included in the SRS; omitted requirement may be related to the behavior of the system, its performance, constraints, or any other factor. Omission directly affects the external completeness of the SRS. Requirements 50

Inconsistency n n n contradictions within the requirements themselves incompatibility of the stated requirements with the actual requirements of the client incompatibility with the environment in which the system will operate. Requirements 51

Incorrect fact n some fact recorded in the SRS is not correct. Requirements 52

Ambiguity n when there are some requirements that have multiple meanings, that is, their interpretation is not unique. Requirements 53

Validation Method: Requirements Review n n requirements are generally textual documents that cannot be executed. Validation Must include client and a user. SRS reviewed by a group of people Group: n n author of the requirements document, someone who understands the needs of the client a person of the design team, person(s) responsible for maintaining the requirements document. Requirements 54

Review process n n Process – standard inspection process Goal: n n reveal any errors in the requirements, consider factors affecting quality, such as testability and readability. Process Effectiveness - can catch 40 -80% of req. errors requirements reviews are needed even if the requirements are specified through a tool or are in a formal notation. Requirements 55

Summary n n Having a good quality SRS is essential for Q&P The req. phase has 3 major sub phases n n Analysis n n n analysis , specification and validation for problem understanding and modeling Methods used: SSAD, OOA , Prototyping Key properties of an SRS: correctness, completeness, consistency, unambiguousness Requirements 56

Summary. . n Specification n n must contain functionality , performance , interfaces and design constraints Mostly natural languages used Use Cases is a method to specify the functionality; also useful for analysis Validation - through reviews Requirements 57