More Related Content
Similar to lecture_Analysis Phase.ppt (20)
Recently uploaded (20)
lecture_Analysis Phase.ppt
- 1. Analysis Phase / Requirement Engineering
- 2. Outline - Problems with requirements practices - Requirements engineering tasks - Inception - Elicitation - Elaboration - Negotiation - Specification - Validation - Requirements management
- 3. 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 (more on next slide)
- 4. 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
- 5. 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
- 6. 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
- 8. Inception Task • 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 • Through these questions, the requirements engineer needs to… – Identify the stakeholders – Recognize multiple viewpoints – Work toward collaboration – Break the ice and initiate the communication
- 9. The First Set of Questions • Who is behind the request for this work? • Who will use the solution? • What will be the economic benefit of a successful solution? • Is there another source for the solution that you need? These questions focus on the customer, other stakeholders, the overall goals, and the benefits
- 10. The Next Set of Questions • How would you characterize "good" output that would be generated by a successful solution? • What problem(s) will this solution address? • Can you show me (or describe) the business environment in which the solution will be used? • Will special performance issues or constraints affect the way the solution is approached? These questions enable the requirements engineer to gain a better understanding of the problem and allow the customer to voice his or her perceptions about a solution
- 11. The Final Set of Questions • Are you the right person to answer these questions? Are your answers "official"? • Are my questions relevant to the problem that you have? • Am I asking too many questions? • Can anyone else provide additional information? • Should I be asking you anything else? These questions focus on the effectiveness of the communication activity itself
- 13. Elicitation Task • 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 • Elicitation may be accomplished through two activities – Collaborative requirements gathering – Quality function deployment
- 14. Basic Guidelines of Collaborative Requirements Gathering • Meetings are conducted and attended by both software engineers, customers, and other interested stakeholders • Rules for preparation and participation are established • An agenda is suggested that is formal enough to cover all important points but informal enough to encourage the free flow of ideas • A "facilitator" (customer, developer, or outsider) controls the meeting • A "definition mechanism" is used such as work sheets, flip charts, wall stickers, electronic bulletin board, chat room, or some other virtual forum • The goal is to identify the problem, propose elements of the solution, negotiate different approaches, and specify a preliminary set of solution requirements
- 15. Quality Function Deployment • This is a technique that translates the needs of the customer into technical requirements for software • It emphasizes an understanding of what is valuable to the customer and then deploys these values throughout the engineering process through functions, information, and tasks • It identifies three types of requirements – Normal requirements: These requirements are the objectives and goals stated for a product or system during meetings with the customer – Expected requirements: These requirements are implicit to the product or system and may be so fundamental that the customer does not explicitly state them – Exciting requirements: These requirements are for features that go beyond the customer's expectations and prove to be very satisfying when present
- 16. QFD process (1) • The basic idea of QFD is to construct relationship matrices between customer needs, technical requirements, priorities and (if needed) competitor assessment. • To achieve this the following process is prescribed: 1. Identify stakeholder’s attributes or requirements 2. Identify technical features of the requirements 3. Relate the requirements to the technical features 4. Conduct an evaluation of competing products 5. Evaluate technical features and specify a target value for each feature 6. Prioritize technical features for development effort.
- 17. QFD process (2) Relationship matrix Target values Competitive eval. Importance weighting How’s Importance weighting Competitive weighting What’s 1 6 5 4 3 2
- 19. Benefits of QFD • Improves user involvement • Improves management support and involvement • Shortens the development lifecycle • Improves project development • Supports team involvement • Structures communication processes • Provides a preventive tool for improving quality • Avoids loss of information
- 20. Summary • Problems with requirement engineering • Requirement engineering process • Inception • Elicitation