1. INTRODUCTION OF REQUIREMENT ENGINEERING Chapter- one

2. What are requirements? Requirements are defined during the early stages of a system development as a specification of what should be implemented or as a constraint of some kind on the system. They may be: a user-level facility description, a detailed specification of expected system behavior, a general system property, a specific constraint on the system, information on how to carry out some computation, a constraint on the development of the system.

3. What are requirements? It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification This is inevitable as requirements may serve a dual function – May be the basis for a bid for a contract – therefore must be open to interpretation – May be the basis for the contract itself - therefore must be defined in detail – Both these statements may be called requirements

4. Requirements abstraction (Davis)

5. Requirements define the “what” of a software product What the software must do to add value for its stakeholders - These functional requirements define the capabilities of the software product. What the software must be to add value for its stakeholders - These nonfunctional requirements define the characteristics, properties, or qualities that the software product must possess. They define how well the product performs its functions. What limitations there are on the choices that developers have when implementing the software - The external interface definitions and other constraints define these limitations.

6. Are requirements important? European Software Process Improvement Training Initiative (1996) “The principal problem areas in software development and production are the requirements specification and the management of customer requirements” In a study of errors in embedded systems, it was found that: “... difficulties with requirements are the key root-cause of the safety-related software errors that have persisted until integration and system testing”

7. What happens if the requirements are wrong? The system may be delivered late and cost more than originally expected. The customer and end-users are not satisfied with the system. They may not use its facilities or may even decide to scrap it altogether. The system may be unreliable in use with regular system errors and crashes disrupting normal operation. If the system continues in use, the costs of maintaining and evolving the system are very high.

8. SW project realities Poorly defined applications (miscommunication between business and IT) contribute to a 66% project failure rate, costing U.S. businesses at least $30 billion every year(Forrester Research) 60% – 80% of project failures can be attributed directly to poor requirements gathering, analysis, and management (Meta Group) 50% are rolled back out of production, 40% of problems are found by end users, testing consumes 25% to 50% of the average application life cycle and often is viewed as adding no business value (Gartner) 25% – 40% of all spending on projects is wasted as a result of re-work (Carnegie Mellon) Up to 80% of budgets are consumed fixing self-inflicted problems (Dynamic Markets Limited 2007 Study)

9. What is requirements engineering? Requirements engineering covers all of the activities involved in discovering, documenting, and maintaining a set of requirements for a computer-based system. The use of the term ‘engineering’ implies that systematic and repeatable techniques should be used to ensure that system requirements are complete, consistent, relevant, etc.

10. Why is requirements engineering difficult? Businesses operate in a rapidly changing environment so their requirements for system support are constantly changing. Multiple stakeholders with different goals and priorities are involved in the requirements engineering process. System stakeholders do not have clear ideas about the system support that they need. Requirements are often influenced by political and organizational factors that stakeholders will not admit to publicly.

11. Types of Requirements 1. User requirements  Are statements of the services the system provides and its operational constraints in natural language, tables and diagrams. Written for customers  Should describe functional and non-functional requirements so that they are understandable by system users who don’t have detailed technical knowledge

12. Problems with natural language Lack of clarity  Precision is difficult without making the document difficult to read Requirements confusion  Functional and non-functional requirements tend to be mixed-up Requirements amalgamation  Several different requirements may be expressed together

13. Types of Requirements… 2.System requirements  A structured document setting out detailed descriptions of the system services.  System requirements may be expressed using system models  Written as a contract between client and contractor 3.Software design specification  An abstract description of the software design that can serve as a basis for a more detailed design. Bridges the gap between requirements and design. Written for developers

14. Requirements engineering processes The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements. However, there are a number of generic activities common to all processes  Feasibility studies  Requirements elicitation and analysis  Requirement specification  Requirements validation  Requirements change management

15. Requirement Engineering Process… Feasibility study Determining if running the project is feasible

16. Feasibility study A feasibility study decides whether or not the proposed system is worthwhile. A short focused study that checks;  If the system contributes to organisational objectives;  If the system can be engineered using current technology and within budget;  If the system can be integrated with other systems that are used.

17. Feasibility study Implementation Based on information assessment (what is required), information collection and report writing. Questions for people in the organisation  What if the system wasn’t implemented?  What are current process problems?  How will the proposed system help?  What will be the integration problems?  Is new technology needed? What skills?  What facilities must be supported by the proposed system?

18. Requirements elicitation & Analysis Sometimes called requirements elicitation or requirements discovery/identification. Involves technical staff working with other stakeholders to find out the services that the system should provide, the system’s operational constraints and the application domain. Multi-disciplinary and human-centred activity. The most difficult, most critical, most error-prone, and most communication-intensive aspect of software development. Requirement Analysis has some tool support  E.g. RequisitePro, MS Visio

19. Requirements Elicitation Requirements elicitation practice include the following:  Interviews  Questionnaires  User observation  Workshops  Brain storming  Use cases  And prototyping

20. Requirements elicitation & analysis process Requirements elicitation & analysis process activities involves:  Domain understanding  Requirement collection  Classification (into coherent clusters)  Conflict resolution and identification of unpractical requirements  Prioritization  Requirement checking (e.g. Eliminate, combined and modified requirements)

21. Requirements analysis D ifferent models may be produced during the requirements analysis activity. Requirements analysis may involve three structuring activities which result in these different models  Partitioning. Identifies the structural (part-of) relationships between entities  Abstraction. Identifies generalities among entities  Projection. Identifies different ways of looking at a problem

22. Requirements Specification A document which is used as a communication medium between the customer and the supplier. When the software requirement specification is completed and is accepted by all parties, the end of the requirements engineering phase has been reached. Requirements can be changed, but the changes must be tightly controlled. The software requirement specification should be edited by both the customer and the supplier.

23. Requirements Specification A Software Requirements Specification (SRS) – a requirements specification for a software system – is a complete description of the behavior of a system to be developed. It includes a set of use cases that describe all the interactions the users will have with the software. In addition to use cases, the SRS also contains non-functional requirements (such as performance requirements, quality standards, or design constraints)

24. Requirements validation l Concerned with demonstrating that the requirements define the system that the customer really wants l Requirements error costs are high so validation is very important Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error

25. Validation Vs. Verification Validation: “Am I building the right product?” checking a work product against higher-level work products or authorities that frame this particular product. Requirements are validated by stakeholders Verification: “Am I building the product right?” checking a work product against some standards and conditions imposed on this type of product and the process of its development. Requirements are verified by the analysts mainly

26. Requirements checking Validity. Does the system provide the functions which best support the customer’s needs? Consistency. Are there any requirements conflicts? Completeness. Are all functions required by the customer included? Realism. Can the requirements be implemented given available budget and technology Verifiability. Can the requirements be checked?

27. Requirements management Requirements management is the process of managing changing requirements during the requirements engineering process and system development Requirements are inevitably incomplete and inconsistent  New requirements emerge during the process as business needs change and a better understanding of the system is developed  Different viewpoints have different requirements and these are often contradictory