Software requirement

Software Requirement Requirements analysis in software engineering encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users. Requirements analysis is critical to the success of a development project. Requirements must be actionable, measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design. Requirement process Need for Software Requirement Specification (SRS) The Software Requirement Specification describes what the proposed software should do without describing how the software will do it. 1. It establishes the basis for agreement between the client and the supplier on what the software product will do. 2. It provides a reference for validation of the final product 3. A high quality SRS is a pre-requisite for high quality product 4. A high quality SRS reduces the development cost as the cost of fixing a requirement error is high as all the phases have to be repeated Requirement engineering tasks 1. Inception: Casual interaction to get product request 2. Elicitation: Ask customer, user and others about their requirements 1. Requirement discovery 2. Requirement classification and organization 3. Requirement prioritizing and negotiation 4. Requirement documentation 3. Requirement elaboration: refinement of user scenarios 4. Negotiation 5. Specification in written document 6. Validation

These are discussed in detail in further sections. Requirement Discovery Requirements discovery is the process of gathering information about the proposed and existing systems and distilling the user and system requirements from this information. Before the system analyst moves on to the task of information collection, he must plan his strategy. The plan must include- • Serialized steps of information collection • List of information to be collected at each step • List of sources for the information to be collected • The enquiry about the purpose of each information • The method of collection of each information Techniques for requirement discovery are discussed as follows: 1. Viewpoints: The requirements sources (stakeholders, domain, systems) can all be represented as system viewpoints, where each viewpoint presents a sub-set of the requirements for the system. There are three generic types of viewpoints: 1. Interactor viewpoints represent people or other system that interact directly with the system. 2. Indirect viewpoints represent stakeholders who do not use the system themselves but who influence requirements. 3. Domain viewpoints represent domain characteristics and constraints that influence the system requirements. 2. Interviewing: Formal or informal interviews with system stakeholders are part of most requirements engineering processes. Interviews may be of two types: 1. Closed interviews where the stakeholder answers a predefined set of questions 2. Open interviews where there is no predefined agenda. For getting the maximum out of an interview, the selection of the right candidate is important. Before starting the interviews, the analyst must write down the hierarchy, or position order of all. The interview must be conducted strictly in that order only, else the integration of information into the system modeling will become impossible, and some information may be lost or may remain unused. It is hard to elicit domain knowledge during interviews for two reasons: 1. All application specialists use terminology and jargon that is specific to a domain. 2. Some domain knowledge may be so familiar to stakeholders that they might forget to mention it. Effective interviews have two characteristics: 1. They are open-minded, avoid preconceived ideas about the requirements and are willing to listen to stakeholders. 2. They prompt the interviewee to start discussions with a question, a requirements proposal or by suggesting working together on a prototype.

Interview Method Personal rapport is the soul of successful interview. The interview of different people has to be conducted depending upon the level and content of information. Before conducting the interview, the analyst must ensure the status and role of the person in the information system. Accordingly, an ordered list of unambiguous questions must be framed for the interview. Each interview must start with simple and convenient questions to encourage the interviewee. After the statement of the interviewee is over, the analyst must summarize his statement to him and get his confirmation. Questions can be closed (requiring a reply) or open (requiring interviewee to speak out his mind). Interviews with introvert type of people must start with closed questions whereas those with extrovert persons must start with open questions. Transition from one to the other type must be gradual and smooth. 3. Scenarios They start with an outline of the interaction, and during elicitation, details added to create a complete description of that interaction. A scenario includes: 1. A description of what the system and users expect when the system starts 2. A description of the normal flow of events in the scenario 3. A description of what can go wrong and how this is handled 4. Information about other activities that might be going on at the same time 5. A description of the system state when the scenario finishes 4. Use-cases These are scenarios based techniques which identify the individual interactions with the system. Actors in the process are represented as stick figures, and each class of interaction is represented as a named ellipse. A use case encapsulates a set of scenarios, and each scenario is a single thread through the use-case. 5. Ethnography is the observational technique that can be used to understand social and organizational requirements. Following two types of requirements can be effectively discovered: 1. Requirements that are derived from the way people actually work 2. Requirements that are derived from cooperation and awareness of other people’s activities

Classification of Requirements When we talk about the detail of requirements in relation to the system, we find two levels. The first is user requirements which are governed by the external users of the system such as client manager, system end-users, client engineers, system architects, etc. These briefly outline the system and are part of high level abstraction specifying the external behavior of the system. The second is system requirement which specifies the characteristics of the system. These define what the system should do. These are defined by the system end-users, client engineers, system architects, software engineers, etc. Each of the above requirements can be further divided as follows: 1. A functional requirement describes an interaction between the system and its environment. (Environmental Model). 2. Non-functional requirement describes a restriction on the system that limits our choices for constructing a solution to the problem. They may relate to emergent system properties such as reliability, response time etc. Failing to meet non-functional requirements can render a system unusable.(Behavioral model) Non-functional requirements can be related to the product, organization (cost, process, quality) or general (such as legislation, ethical). These requirements are difficult to verify because they are not easily quantifiable. 3. Domain requirements are defined by similar systems implemented. These may be functional or non-functional and are important, as they reflect fundamentals of the application domain. The third is interface specification which defines the procedure interface (APIs), Data Structures and representation of Data structures. Types of requirements: 1. Physical environment under which the system should work. 2. Interfaces required for interaction with the external environment 3. User and human factors that affect the operation of system. 4. Functionality desired by the system. 5. Documentation needs can be specified by the management. The time for such documentation can also be specified. 6. Data resource should be carefully defined for the system as data is a precious resource. 7. Resources apart from above should be mentioned, if they are involved with the system. 8. Security requirements are very important for systems dealing with critical resources. 9. Quality Assurance requirements as stated by the user or standards followed, should be mentioned in the requirements report to allow verifications and inspections. Evaluation: The requirements that have been gathered need to be evaluated to resolve inconsistencies and also to understand why each requirement has been stated. In this task the analyst needs to do the following: o For every requirement X, get answers to question “Why do you need X?” o Convert any requirements stated as “how to” into the corresponding “what” is required. o Capture rationale to support future requirements

o Perform risk assessment, feasibility and cost/benefit analysis considering the technical, cost and schedule concerns. A risk assessment is also performed to address technical, cost and schedule concerns. The rationale behind the information gathered in the previous stages is examined to determine whether the true requirements are hidden in this rationale instead of being expressed explicitly. Internally and commercially available software products and components are evaluated for possible reuse. Prioritisation: The requirements are then prioritised based on cost and dependency and user needs. Knowing the rationale behind each requirements helps in deciding the priority Consolidation is required to put together all the requirements in a way that can be analysed further. It comprises: o Filling in as many ‘to be determined’ issues as possible o Validating that requirements are in agreement with originally stated goals o Removing inconsistencies o Resolving conflicts o Authorizing/ verifying to move to the next step of development, i.e. detailed requirements analysis Often group development techniques are used for consolidation because they remove the possibility of an individual’s interpretation of the requirements. Expressing Requirements Following representational techniques are used: 1. Static descriptions: A static description lists the system entities or objects, their attributes, and their relationships with each other. This view is static because it does not describe how relationships change with time. Different ways to describe a system statically are: 1. Indirect reference is made to the problem and its solution 2. Recurrence relation like Fibonacci 3. Axiomatic definition with the help of axioms/ theorems to specify basic system properties 4. Expression as a language (PDL) 2. Dynamic descriptions 1. Decision tables represent a actions to be taken when the system is in one of the states illustrated. 2. Functional description and transition diagrams (automata) 3. Event tables represent system’ states and transitions in a tabular form. 4. Petri nets representing a graphical system by drawing a node for each state and an arrow to mark the transitions with a given input. 3. System models are graphical representations that describe business processes and the problem to be solved. Context models: Architecture models describe the environment of the system. They are supplemented by process models. Example:

Behavioral models: They describe the overall behavior of the system. Examples are dataflow diagrams and state machine models. 1. Data flow models are used to show how data flows through a sequence of processing steps. It shows a functional perspective where each transformation represents a single function or process. These are valuable because tracking and documenting how data associated with a particular process moves through the system helps analysts understand what is going on. The development of models such as data flow models should be a top-down process. 2. State machine models describe how a system responds to internal or external events. This type of model is often used for modeling real-time systems since these systems are often driven by stimuli from system’s environment. 3. Data flow diagrams Data models: Most widely used technique is Entity-relation-Attribute modeling. Defining the logical form of the data processed by the system is called semantic data modeling. Like all graphical models, data models lack detail. One may collect these descriptions in a repository or data dictionary. Advantages of data dictionary are : 1. It is a mechanism for name management. 2. It serves as a store for organizational information. Object models: Here system requirements are expressed using object model, designing using objects and developing the system in an object-oriented programming language. Developing object models during requirements analysis usually specifies the transition to object-oriented design and programming.

1. Inheritance model 2. Object aggregation 3. Object behavior modeling Critical system specification High potential costs of system failure cause the specification for critical systems to accurately reflect the real needs of users of the system. These are the requirements that should be a part of requirements report. 1. Risk driven specification is an approach that has been widely used by safety and security critical systems developers. It is applicable to any system where dependability is a critical attribute. 2. Safety specification process in its first stage defines the scope of the system, assesses the potential system hazards and estimates the risk they pose. This is followed by safety requirements specification and the allocation of these safety requirements to different sub- systems. These requirements are broken into functional safety requirements and safety integrity requirements. After delivery, the system must be installed as planned so that the hazard analysis remains valid. 3. Security specifications are based around the assets to be protected and their value. The steps involved are asset identification and evaluation of the degree of protection, threat analysis and risk assessment, threat assignment to the assets, analysis of available technology and finally specification of security requirements. Different types of security specifications are authentication and authorization requirements, immunity requirements, intrusion detection requirements, non-repudiation requirements, privacy requirements etc. Requirement Elaboration The information obtained from the customer during inception and elicitation is expanded and refined. It focuses on developing a refined technical model of software functions, features, and constraints. The end result is an analysis model that defines the informational, functional, and behavioral domain of the problem. Requirement Negotiation It might be that different users have conflicting requirements. To reach a consensus these requirements are prioritized by all parties and the most important requirements

become part of the document. Risk associated with each requirement is identified and evaluated. The finalized requirements are used to assess approximate effort, time and cost for the project. Finally the baseline is defined. Requirements documentation 1. Requirement definition is a complete listing of everything the customers expects the system to do. It is written jointly by the customer and developer. First we outline the general purpose of the system; next we describe the background and objectives of system development. We outline a description to the solution. Next we describe the detailed characteristics of the proposed system. Finally we discuss the environment in which the system will operate. 2. Requirement specification restates the requirements definition in technical terms appropriate for the development of system design. It is written by requirements specialists. The specification document may define the same requirements as in the definition document as a series of equation. Contents of an SRS 1. Introduction This chapter contains purpose of the document, scope of the document, an overview of the requirements and the context in which the document was prepared 2. General Description In this chapter, the proposed product is described in the context of existing systems, user characteristics, problems faced, objectives of the proposed system and any known constraints. 3. Functional Requirements This chapter lists all the functional requirements in the decreasing order of importance. For each requirement, a description, criticality, risks and dependencies with other requirements is documented. 4. Interface Requirements This chapter is used to describe the user interfaces, hardware interfaces, communications interfaces and interfaces to other software systems. 5. Performance Requirements Speed and throughput requirements are described in this requirement 6. Design Constraints This chapter specifies the design constraints imposed on the design team and could cover standards to be complied with, hardware limitations, etc. 7. Other Non-Functional Attributes Aspects such as security, reliability, maintainability, etc. that are important to the project are described in this chapter. 8. Preliminary Domain Analysis This chapter contains the modelling of the proposed system. 9. Operational Scenarios This chapter contains the main scenarios (use cases) that will be experienced from the proposed system. 10. Schedule and Budgets This chapter can contain the estimates and a high-level project plan.

Characteristics of a good Software Requirement Specification 1. Completeness can be aimed by ensuring the following: • Elicitation of the requirements from all the “stakeholders” • Focus on user tasks, problems, bottlenecks and improvements required; rather than the system functionality • Ranking or prioritising each requirement (functional as well as non-functional) for importance. • Marking areas where requirements are not known as “To Be Determined” • Resolving all ‘to be determined’ requirements before the design phase. 2. Clarity (Unambiguous) is related by following issues • Requirements should be reviewed by an independent entity to identify ambiguous use of natural language. • Specifications should be written in a requirement specification language. • Requirements can also be expressed using requirements analysis and modelling techniques. 3. Correctness can be assumed if every requirement stated in the SRS is required in the proposed system. All stakeholders need to review the SRS and confirm that the SRS correctly reflects their needs. 4. Consistency can be maintained when any conflict between requirements within the SRS is identified and resolved. Logical conflicts should be identified and removed. 5. Modifiability can be increased by proper documentation. Certain practices that can lead to high modifiability are: • Minimal redundancy leads to lower inconsistencies when changes are incorporated. • Labelling helps easily identify changed requirements. 6. Traceability cab is created by labelling all requirements and following them all through the designing phase, test phase and so on. Fine grained, structured and precise statements are much more preferable to large, narrative paragraphs. Traceability can be backward or Forward. 7. Feasibility should be checked before including any requirement 8. Testability (Verifiability) should be enhanced by stating the requirements correctly. 9. Ranked for importance and/or stability to ensure the most important ones are incorporated early and carefully. Requirement Validation A number of requirements validation techniques can be used in conjunction or individually: 1. Requirements review where requirements are analyzed systematically by a team of reviewers. The development team should explain all requirements and their implications to the reviewing team in a formal review. In an informal review, the team interacts with stakeholders to verify requirements. In both cases the team reviews the requirements for consistency, verifiability, comprehensibility, traceability and adaptability. Conflicts, contradictions, errors and omissions are pointed out by the review team. 2. Prototyping helps to ensure the correct requirements are found. Throwaway prototype, where the prototype is discarded after correcting requirements is prepared, when the not well understood requirements are significant for system. Otherwise exploratory prototype is built which enhances the prototype once built.

3. Test case generation is a technique which prepares test cases for the requirements and ensures that they are correctly stated. 4. Validation can be done by using checks on 1. Validity of requirements 2. Consistency to avoid contradiction 3. Completeness to include all constraints 4. Realism check to see if it can be really implemented 5. Verifiability ensures that test cases can be generated to check requirements Common problems with Software Requirement Specification 1. Making Bad Assumptions due to lack of proper or no information. 2. Writing implementation (HOW) instead of requirements (WHAT) 3. Using incorrect terms such as ‘will not be limited to’, ‘such as’ etc. 4. Using Wrong Language which is ambiguous 5. Unverifiable Requirements that are written using terms such as maximize, fast, sometimes etc. 6. Missing Requirements can be avoided using proper templates 7. Over-Specifying or stating unnecessary things Requirements management consists of: 1. Requirements change management which involves systematic handling of changes to agreed requirements (SRS) during the course of the project. Changes occur because there are changes in the business and technical environment and preferences and priorities of users change. Some requirements are enduring, i.e. relatively stable, and there are volatile requirements that change over time. Change management process is as follows: Initiation Further Impact analysis Impact analysis Pending partly rejected Evaluation approved Planning Execution Closing Change Management process 1. Initiation: A change request form (CRF) is filled. It includes why such a change is required, what benefits are expected with the change, or what difficulties will be faced without the change.

2. Impact Analysis: The CRF is handed over to the Configuration Controller, who in cooperation with others, evaluates the change from various perspectives e.g. technical feasibility, additional resources, additional calendar time, impact on current activities etc. 3. Evaluation: The change is presented in the periodic Change Control Board (CCB) meeting which may accept, reject, partially approve, keep pending or perform further impact analysis for the proposed change. 4. Planning: If CRF is partially or fully approved, the Configuration controller fill sup the implementation plan for implementing the CRF. 5. Execution: changes are made according to the implementation plan. 6. Closing: The CRF is closed after verifying that all changes that were required have been made. 2. Requirements traceability consists of maintaining traceability between the agreed (and changed) SRS and the other work products (like design documents, test plans) created downstream in the software life cycle. Test case TC01 TC02 TC03 TC04 ...... TC49 requirement R-01 X X X R-02 X x R-03 x X : R-096 X There are three types of traceability information that may be maintained. 1. Source traceability information links the requirements to the stakeholders who proposed the system. 2. Requirements traceability information links dependent requirements within the requirements document. This helps in assessing how many requirements are likely to be affected by a proposed change. 3. Design traceability information links the requirements to the design modules where these requirements are implemented. 3. Tools for requirement documentation are also available. A few are a. PSL/PSA: Problem statement language specifies the requirements which are converted into models by the problem statement analyzer. b. RSL/REVS: Requirement statement language specifies the requirement and Requirement engineering validation system processes and analyzes RSL statements. REVS consists of a translator for RSL, Centralized database and a set of automated tools. c. Structured analyses and design technique (SADT) creates a model that consists of a set of ordered SA diagrams. d. Structured System Analysis (SSA) includes data flow diagrams, data dictionaries, and procedure logic representations and data store structuring techniques. Key enablers that drive the maturity of the requirements engineering process are:

1. Senior management reviews requirements engineering for process compliance 2. Independent Software Quality Assurance group reviews requirements engineering for process compliance. 3. Project manager monitors the progress of requirements engineering activities 4. Requirements engineering responsibility is explicitly assigned in each project. 5. Tools required for facilitating requirements engineering activities are explicitly identified, made available and used. 6. Persons performing requirements engineering activities are trained/ skilled in the application domain and requirements engineering process. Other project members are provided the appropriate orientation on the application domain and requirements engineering process. 7. Tools and resources are available to be able to maintain the requirements related information and documents of past projects that may be re-used. Commandments for Requirements 1. Don’t ignore the other side (LISTEN) 2. Understand the Domain (CONCEPTS) 3. Understand Why They Want it and How Badly (UNDERSTAND THEM BETTER) 4. Don’t be in a hurry (IT IS THE MOST IMPORTANT STAGE) 5. Do not Consider Anything as Obvious (DOCUMENT EVERYTHING) 6. Don’t Sweep it Under the Carpet (DON’T IGNORE ISSUES) 7. Don’t say “Yes” when you may need to say “No” (PROCEDURES FOR CHANGE MANAGEMENT) 8. Work as a team 9. Don’t expect Analysts to Read your Mind 10. Don’t Just Sign-off without Rigorous SRS Review Requirement metrics Requirements can be measured on various parameters. A few commonly used measurable are: • Function point metrics is a calculation dependent on the characteristic of requirement. • Number of requirements can be used as a measure • Number of changes to requirements is measured during the iterations • Requirements size looks at the bigger picture of project size and complexity • Kinds of requirements are important to be identified, because critical requiremenst are more difficult to implement. Function point calculation Factor Value Backup and recovery 4 Data Communications 2 Distributed processing 0 Performance critical 4 Existing operating environment 3

On-line data entry 4 Input transaction over multiple screens 5 ILFs updated online 3 Information domain values complex 5 Internal processing complex 5 Code designed for reuse 4 Conversion/installation design 3 Multiple installations 5 Application designed for change 5 Value adjustment factor 1.17 Information domain Opt Likely Pess Est. count Weight FP count No. of external inputs 20 24 30 24 4 97 No. of external outputs 12 15 22 16 5 78 No. of external inquiries 16 22 28 22 5 88 No. of internal logical files 4 4 5 4 10 42 No. of external interface files 2 2 3 2 7 15 Count total 320 FP=count-total*[0.65+0.01*(Fi)] FP=375

Software requirement

by Ram Dutt Shukla on Apr 10, 2010

Accessibility

Upload Details

Usage Rights

1 Embed 2

Statistics

Software requirement — Document Transcript