Lecture 1 - Requirement Engineering.pptx
- 2. Requirement Engineering • Objective: To understand Issues in Requirements Engineering, to understand and apply Requirements Engineering Process, to understand and use Requirements Elicitation and Specification, to understand and use Formal Techniques, to understand modelling and analysis of Non- Functional Requirements • Reference Book: •Hull, Jackson, and Dick, Requirements Engineering, 2004, Springer •Karl E. Wiegers, Software Requirements, 2nd Edition, 2003, Microsoft Press •Loucopoulos and Karakostas, System Requirements Engineering, McGraw- Hill , 1995 •Kotonya and Sommerville, Requirements Engineering: Processes and Techniques, John Wiley Sons, 1998.
- 3. Lecture 1-Outline -Requirement Engineering -Role of Requirement Engineering in Software Development -Problems with requirements practices - Requirements engineering tasks
- 4. Requirement Engineering • Requirements Engineering (RE) is a set of activities concerned with identifying and communicating the purpose of a software-intensive system, and the contexts in which it will be used. • Hence, RE acts as the bridge between the real-world needs of users, customers, and other constituencies affected by a software system, and the capabilities and opportunities afforded by software-intensive technologies.
- 6. Role of Requirement Engineering in Software Development • Requirements engineering (RE) is the most important area of Software engineering and possibly of the entire software life cycle. Because errors produced at this stage, if undetected until a later stage of software development, can be very costly. • If it can specify the requirement specification correctly, errors of later stages will be less. Hence software developments and maintenance cost will be less moreover customer will get their desire system.
- 7. Role of Requirement Engineering in Software Development (Cont…) • The cost of fixing errors: – One of the best-known investigations of the economics of software development was a series of studies conducted in the 1970’s by Barry Boehm. Boehm investigated the cost to fix errors in the development of large software systems. – Most of the projects followed a fairly standard sequence of phases: requirements analysis, design, coding (programming), development testing, acceptance testing and operation. Errors made in a particular phase cost more to fix the longer they are left undetected, so that, for example, a programming error that is not discovered until acceptance testing will cost ten times as much to fix than if it is found during programming. A requirements error not found until after delivery will cost a hundred times more to fix. – The explanation is fairly simple –the longer a problem goes unnoticed, the more subsequent design decisions are based on it, and hence the more work it will take to unpick them.
- 8. Role of Requirement Engineering in Software Development (Cont…) • Boehm’s data invites a number of conclusions, the main one of which is that the strict sequence of phases described above (known as the waterfall model) may not be the best way to manage a large project – an iterative approach may be more suitable. • The conclusions concerning the relative cost of fixing errors do not necessarily depend on the order in which things are done, because the cost driver is not the length of time that an error goes undetected, but the number of other decisions that are based on it. • Errors made in understanding the requirements will always have the potential for greatest cost to fix, because so many other design decisions depend on them. Clearly, time invested in understanding the requirements early in a project can have a significant payoff.
- 9. The Problems with our Requirements Practices • We have trouble understanding the requirements that we do acquire from the customer • We often record requirements in a disorganized manner • We spend far too little time verifying what we do record • We allow change to control us, rather than establishing mechanisms to control change • Most importantly, we fail to establish a solid foundation for the system or software that the user wants built 9
- 10. The Problems with our Requirements Practices (continued) • Many software developers argue that – Building software is so compelling that we want to jump right in (before having a clear understanding of what is needed) – Things will become clear as we build the software – Project stakeholders will be able to better understand what they need only after examining early iterations of the software – Things change so rapidly that requirements engineering is a waste of time – The bottom line is producing a working program and that all else is secondary • All of these arguments contain some truth, especially for small projects that take less than one month to complete • However, as software grows in size and complexity, these arguments begin to break down and can lead to a failed software project 10
- 11. A Solution: Requirements Engineering • Begins during the communication activity and continues into the modeling activity • Builds a bridge from the system requirements into software design and construction • Allows the requirements engineer to examine – the context of the software work to be performed – the specific needs that design and construction must address – the priorities that guide the order in which work is to be completed – the information, function, and behavior that will have a profound impact on the resultant design 11
- 12. Requirements Engineering Tasks • Seven distinct tasks – Inception – Elicitation – Elaboration – Negotiation – Specification – Validation – Requirements Management • Some of these tasks may occur in parallel and all are adapted to the needs of the project • All strive to define what the customer wants • All serve to establish a solid foundation for the design and construction of the software 12
- 13. Requirements Engineering Tasks (Cont…) • Inception – During inception, the requirements engineer asks a set of questions to establish… • A basic understanding of the problem • The people who want a solution • The nature of the solution that is desired • The effectiveness of preliminary communication and collaboration between the customer and the developer
- 14. Requirements Engineering Tasks (Cont…) • Elicitation – Gathering requirements in detail – Eliciting requirements is difficult because of • Problems of scope in identifying the boundaries of the system or specifying too much technical detail rather than overall system objectives • Problems of understanding what is wanted, what the problem domain is, and what the computing environment can handle (Information that is believed to be "obvious" is often omitted) • Problems of volatility because the requirements change over time
- 15. Requirements Engineering Tasks (Cont…) Elaboration • During elaboration, the software engineer takes the information obtained during inception and elicitation and begins to expand and refine it • Elaboration focuses on developing a refined technical model of software functions, features, and constraints • It is an analysis modeling task – Use cases are developed – Domain classes are identified along with their attributes and relationships – State machine diagrams are used to capture the life on an object • The end result is an analysis model that defines the functional, informational, and behavioral domains of the problem
- 16. Requirements Engineering Tasks (Cont…) • Negotiation – During negotiation, the software engineer reconciles the conflicts between what the customer wants and what can be achieved given limited business resources – Requirements are ranked (i.e., prioritized) by the customers, users, and other stakeholders – Risks associated with each requirement are identified and analyzed – Rough guesses of development effort are made and used to assess the impact of each requirement on project cost and delivery time – Using an iterative approach, requirements are eliminated, combined and/or modified so that each party achieves some measure of satisfaction 16
- 17. Requirements Engineering Tasks (Cont…) • Specification – A specification is the final work product produced by the requirements engineer – It is normally in the form of a software requirements specification – It serves as the foundation for subsequent software engineering activities – It describes the function and performance of a computer-based system and the constraints that will govern its development – It formalizes the informational, functional, and behavioral requirements of the proposed software in both a graphical and textual format 17
- 18. Requirements Engineering Tasks (Cont…) • Validation – During validation, the work products produced as a result of requirements engineering are assessed for quality – The specification is examined to ensure that • all software requirements have been stated unambiguously • inconsistencies, omissions, and errors have been detected and corrected • the work products conform to the standards established for the process, the project, and the product – The formal technical review serves as the primary requirements validation mechanism • Members include software engineers, customers, users, and other stakeholders 18
- 19. Requirements Engineering Tasks (Cont…) • Requirement Management – During requirements management, the project team performs a set of activities to identify, control, and track requirements and changes to the requirements at any time as the project proceeds – Each requirement is assigned a unique identifier – The requirements are then placed into one or more traceability tables – These tables may be stored in a database that relate features, sources, dependencies, subsystems, and interfaces to the requirements – A requirements traceability table is also placed at the end of the software requirements specification 19