درس :مهندسي نيازمندي ها استاد: دكتر عبداله زاده دانشجو: خيرالنسا مرچانت Software Requirements

1. درس :مهندسي نيازمندي ها استاد: دكتر عبداله زاده دانشجو: خيرالنسا مرچانت Software Requirements

2. 1.Introduction • This paper contributes to specification, validation of software requirements system and specific software development life cycle models. • The activities such as elicitation, analysis, specification, validation, requirements management and quality requirement specification are also described in this paper.

3. Requirement process describes five primary disciplines shown in figure 1 are as follows:

4. Elicitation: It is concerned with proactively working stakeholders to discover their needs, identify and negotiate potential conflicts and establish a clear scope and boundaries for the projects. • Analysis: It is a deeper understanding of products and its interactions: identifying requirements with global impact in order to define the high level architectural design.. • Specification: It is the production of a series of documents that capture the system and software requirements to support their systematic review, evaluation and approval. • Management: It starts from the moment the first requirement is elicited and ends when system is finally decommissioned. It includes software configuration management, traceability, impact analysis and version control. • Validation: It ensures that the product meets stakeholders’ requirements through activities such as formal and informal reviews and for more complex or critical systems through the use of formal verification techniques

5. 2.Defining a Requirement • There are 3 definition for requirements: • A condition or capability needed by a user to solve a problem or achieve an objective. • A condition or capability that must meet or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents. • A document representation of a condition or capability as stated in (1) or (2).

6. Description of types of requirements shown in figure2 are as follows:

7. Product requirements: It can be either functional or non-functional and describe properties of actual system that is to be delivered. • Functional Requirement: It describes what the system needs to do, such as a requirement for an online banking portal. • Quality or NFR: It describes a constraint upon the solution space, capturing a broad spectrum of systemic qualities such as reliability, portability, maintainability, usability, safety and security. • Process requirements: It specify constraints placed upon the development process, e.g. the system developed to run on the J2EE platform. Process requirement can also be shown in SOW (Statement of work).

8. 3.Elicitation • It concerns with proactively working stakeholders to discover their needs, identify and negotiate potential conflicts, and establish clear scope and boundaries for projects. • Requirement elicitation focuses on gathering knowledge about the needs of the stakeholders through helping them to understand and articulate their problems and through describing their vision of what they would like the new system to do. • Several dimension of requirement elicitation are understanding the problem and its domain, identifying clear business objectives for projects and understanding the need of constraints of system stakeholders.

9. 3.1 Understanding the problem and its Domain • The first step in elicitation process occurs at the very start of the project during an activity referred as “project blastoff”. In this phase the problem domain is explored in order to understand the context. • Here the task can be simplified by decomposing the domain into sub-domains e.g. preliminary decomposition of an emergency dispatch center that identifies sub-domain such as GPS tracking, emergency services like police, fire services and call dispatch.

10. The require elicitor works with an initial group of stakeholders to identify the sub-domains of problem, Once sub-domains are specified an additional set of stakeholders or “Subject Matter Experts” (SME ) are selected to explore each one fully. • Alexander and Robertson identify stakeholder role through the use of “onion model” in which the centered of onion represents the product to be developed and the outer layer represents progressively more distant types of stakeholders. • It is the job of elicitors to initially steer stakeholders away from offering premature solution until the problem space is well defined.

11. 3.2 Making the Business Case • Prior to committing to a project, the customer and business stakeholders should perform a business analysis to more fully understand the costs, risks and anticipated benefits from projects. In high level requirements the risk and benefits analysis provide the basis for determining whether the project should proceed or not e.g. extensive case study examining the catastrophic failure of the London Ambulance System in late 1990’s Finkelstein observed that similar systems of smaller scope had been successfully and incrementally delivered to other regions in England.

12. 3.3 Elicitation Techniques: • The role of elicitor is to learn needs of the users and to communicate these needs effectively to the developers. • There are five elicitation techniques as follows: • Collaborative sessions: • They are in ala shapes and sizes and are primarily useful for brainstorming and problem solving activities such as JAD (Joint Application Design). • Collaborative methods are useful for identifying and negotiating conflicts that might exist between requirements.

13. Interviewing techniques: • It is one of the simplest and most effective method of requirement engineering. • Interviews can be either structured or unstructured. • Structured interviews have the advantage that all interviewees are asked the same questions and critical questions are not inadvertently forgotten. • In unstructured interviews the interviewer may ask a few leading questions. • Interviews are conducted in stages so that responses from first round can be used to generate a deeper set of more focused questions for the second round.

14. Questionnaires • Questionnaires tend to be used more frequently in the form of market research surveys when developing a product for an external client or to elicit a general response from a targeted group of stakeholders such as the users of an existing system. • Ethnography • It involves the way users interact with an existing system. • Studying how a user currently performed a task and noting problems and possible areas of improvement that can identify the users requirements. • It can also observe shortcuts and work-arounds that may have developed by power users.

15. Prototyping • It is a useful technique for taking an early set of user requirements and rapidly building a ‘system’ that can be used to elicit additional requirements. • There are several types of prototypes: • Low fidelity models: built with pen and paper, index, cards,… • High fidelity models: that utilize rapid development techniques to deliver a semi- functioning product to the user which is useful for eliciting feedback.

16. Documentation • Documents come in a variety of shapes and sizes such as problem reports, memos, user manuals from existing systems, existing designs and specifications, reports output from existing systems, documentation from competitors’ products and previously written contracts. • Modeling • It is used as a means of communicating back to the user specifiers understanding their needs .A broad rang of methods such as DFD (data flow diagram), state charts, use cases and sequence diagrams are available. • A model is useful during elicitation if it helps the elicitor to figure out which questions to ask or if it surfaces hidden requirements. • Formal models are not that useful during the elicitation process primarily because they are typically not well understood by stakeholders.

17. Roleplaying • They are used to explore stakeholders needs when stake holders are unavailable • Checklists of NFRs • They are useful to help stake holders to identify the non-functional needs of the system. • They are useful tool for triggering discussions.

18. 3.4 Conflict Identification and Negotiation • The requirements elicitor is responsible for identifying inconsistencies and unresolved issues in the gathered requirements. • There are two primary sources of conflicts: • Stakeholders may have conflicting ideas concerning the functionality of the new system. • Conflicts related to non-functional requirements such as performance, cost and security. • In projects where requirements are written textually rather than formally conflicts are identified through a qualitative reviews of requirements.

19. 4. Require Analysis • In this phase the emphasis is upon gaining understanding of the product to be developed through requirements classification according to priority and scope, candidate architecture, allocate requirements to components, evaluate the impact architecture and negotiate architecturally the related tradeoffs , and conceptual modeling.

20. 4.1ConceptualModeling • Earlier models were primarily used to elicit further requirements but now they are used to gain a deeper understanding of requirements. • There are several types of models that are useful including data and control flows, state models, event traces, object models, and user interaction • Selection of specific modeling notation is dependent upon many factors including the nature of problem domain, the expertise of the software engineer performing the modeling, process requirements established y customer and availability of supporting tools. • However there is advantage of using a widely accepted industry standard such as UML because it is simple and understood by a broader range of stakeholders, IEEE defines two standard notations for conceptual modeling one is IEEE Std 1320.1,Idef0 for functional modeling and the second is IEEE Std 1320.2, IDEF1 x97 for information modeling.

21. 4.2 Architectural Design and Requirements Allocation • In this stage requirements are categorized to differentiate between process , product requirements and identify requirements . • Architectural quality measured by its ability to fulfill the stated requirements • Several architectural techniques such as • ATAM (Architectural Trade-off Assessment Method) used to evaluate the ability of architecture to fulfill the requirements. • NFR framework provides a frame work for reasoning about tradeoffs between requirements and assessing the impact of various implementation decisions upon NFRs. • Evaluating architectural quality during the elicitation and analysis process provides insights into conflicts, tradeoffs, and missing requirements and development of higher quality set of requirements.

22. 5. Requirements Specification • The requirement specification is a document that describes the system to be developed in a format that can be reviewed, evaluated and approved in systematic way. • Three distinct type of document shown in figure4 are systems definition document, systems requirements document and software requirements documents.

24. System definition document which is commonly called the user requirement document or the Concept of Operations is written using domain terminology and defines the high-level system requirements from domain perspective • Systems requirement document is used in systems with substantial non-software components. It specify interfaces between hardware and software. • SRS (Software requirements specification) defines what the software component of the product is expected to do and when necessary explicitly states what it should not do. • SRS are used to identify risks, estimate cost and schedule, drive the design and implementation of the system, and to act as a contractual agreement to support eventual customer acceptance of the product.

25. SRS is created as a hierarchical document including introduction, constraints, assumptions, dependencies etc.. • SRS describes both functional and non-functional requirements. • SRS is written in natural language. • A supporting document known as the requirements definition document provided clear definitions of all the terms used in the specification.

26. 5.1 Qualities of an individual Requirement • To minimize errors during requirement phase each requirement should have the following qualities: • Concise: A requirement should be stated in clear, simple and understandable terms. Whenever a precondition or constraint is applicable to a single requirement it can be attached as a constraint on that requirement. • Correct: A requirement should accurately describe the property of the system with no information missing that is needed to define or implement the system.

27. Non-ambiguous: A requirement should be stated clearly and understandably in order to avoid ambiguous interpretations. • Feasible: A requirement should be feasible from technical, financial and managerial perspectives. • Verifiable: • A requirement should be written in such a way as to provide a clear and testable acceptance criterion. • To remove ambiguity verification method need to be agreed contractually in requirements document. • It is useful to attach attributes to each requirement in order to manage more effectively. • Requirements state the needs of user and do not contain unnecessary design constraints for e.g. a requirement for a computerized stopwatch might say that “timer shall be reset by the user”.

28. 5.2 Qualities of the set of Requirements • The four set of qualities applied to requirements are as follows: • Realistic: Here requirements should represent both the product and project level. • Concise: Requirements should describe the system that is to be developed. • Complete: Requirements should collectively • describe the entire system to be implemented with no information missing. • Consistent: Inconsistencies should be identified and conflicts are negotiated.

29. 6. Validation • Validation falls under the general heading of V&V or verification and validation. • IEEE standard 1012-1998 defines requirements validation as the process of evaluating an implemented system to determine whether it conforms to be specified requirements. • SWEBOK (Software Engineering Body of Knowledge) defines validation as the process of ensuring that the engineer has understood the requirements correctly, in other words “Have we got the right requirements?”, while verification is defined as the process of ensuring the requirements documents conform to specified standards. Verification addresses the question of “Have we got the requirements right?”. • Validation practices should be built into every stage of the requirements process in order to ensure a quality products. • There are four methods for validation as follows:

30. Reviews: • Reviews are conducted by stakeholders with the intent of finding errors, conflicts, incorrect assumptions, ambiguities and missing requirements • Formal inspections and reviews have shown to be effective in removing errors early in the process, reducing the cost and efforts involved in fixing downstream problems. • Reviews are useful at all major milestone including completion of the system definition document, system requirements document, SRS …. • As reviews require significant time commitments so they are costly to conduct, therefore it is beneficial to perform pre-review activities to identify and handle obvious errors in advance.

31. Prototyping: • It is useful for validating software engineering interpretation of users need. • Stakeholders provide more useful feedback when interacting with prototyping than when they simply read an SRS • Requirements developed with prototype are less volatile than those developed without it. • Model validation: • It is used to verify the correctness of the system. • Conceptual model can be formally or informally validated either by statically analyzing the model or in the case of formal specification by applying reasoning to prove the properties of the system. • Acceptance tests: It is used to validate that the complete product fulfills the requirements of the system. Therefore all requirements including non-functional should be specified in a way that they can be validated.

32. 7. Requirements Management • Almost software product continues to change and evolve throughout its lifetime, therefore if changes are not managed well the quality of the product will deteriorate and future changes will become increasingly difficult to accommodate. • Change management should carefully control changes both during the development process and following product’s deployment. • Change management is supported through requirements traceability, managing the current status of all requirements and through placing requirements under configuration control. • The three require managements are as follows:

33. Requirements traceability: It is defined as “ The ability to describe and follow the life of a requirement in both a forward and backward direction (i.e. from its origins, through its development and specification…..) • A trace defines a relationship between two artifacts. • Unnecessary traces lead to a maintenance nightmare while too little traceability provides inadequate support for the change process.

34. Change requests: It should be managed systematically. Request for change (RFC) once created, impact analysis and changes prioritized and assessed in terms of benefits, cost and efforts. • Requirements attributes: Each requirement is assigned a unique identifier for tracking purposes and auxiliary attributes are used to record information such as change dates, rationales and current status.

35. 8. Conclusions • Here traditional approach to requirements engineering in which requirement process involves elicitation, analysis, specification validation and management has been described. • Agile philosophy has challenged the accepted wisdom that the cost of change increases over time and changes the customer throughout the development process. • Boehm and Turner point out that agile method is more suitable for smaller, volatile and non-critical projects.