It’s not just a simple matter of writing down what the customer says he wants !!! Requirement Engineering Lesson 01: The Importance of Requirements Lecturer: Email: Web: Nguyễn Ngọc Tú Tu.NguyenNgoc@hoasen.edu.vn sites.google.com/site/kythuatthuthapyeucauphanmem/ 2012.08 Learning Outcomes Requirement Engineering Issues  Requirement   2012.08 SoftProj Fail Rate Dynamic Change over time Failed Succeeded Challenged  Good requirements   + Process must be as accurate as possible be flexible  Process  developing requirements and accommodating changed requirements  the real requirements of customers [1] chapter 01, p001 Requirement Engineering 2012.08 Requirement Engineering 2012.08 Requirement Engineering 2012.08 Outline  What are Requirements and Why Are They Important?  Why Plan?  A Suggested Strategy  Requirements Activities in the System Life Cycle  Investment in the Requirements Process  A Process Approach  The Requirements Plan  Factors Affecting Your Career Decisions  A Comment Concerning Small Projects  Case Study [1] chapter 01 Requirement Engineering 2012.08 What are Requirements & Why Are They Important? A requirement is anything that the business needs to have implemented in the solution  Requirements, therefore, can include functional requirements, non-functional requirements, business rules, and even what many people traditionally call design Requirement The system shall be able to automatically approve or deny credit When the credit score is above 750, the system shall automatically approve credit The system shall use the following algorithm when automatically determining credit approvals for scores less than 750: [ algorithm would be included here ] Approvals shall be returned to the user within 30 seconds Requirements are what needs to be built, and design is how it will work Type Functional requirement Business rule Business rule Non-functional requirement Requirement Engineering 2012.08 What are Requirements & Why Are They Important?  A requirement is a necessary attribute in a system ,  a statement that identifies a capability, characteristic, or quality factor of a system in order for it to have value and utility to a customer or user   Require-ments are important because they provide the basis for all of the develop-ment work that follows  Once the requirements are set, developers initiate the other technical work: system design, development, testing, implementa-tion, and operation Requirement Engineering 2012.08 What are Requirements & Why Are They Important? “stated” requirements provided by a customer at the beginning of a system or software development effort • “real” requirements reflect the verified needs of users for a particular system or capability a request for information, proposal, or quote or in a statement of work (SOW) Requirement Engineering 10 2012.08 Ex A long list of requirements REQ ID REQ001 REQ002 REQ003 REQ004 REQ005 REQ006 REQ007 REQ008 REQ009 REQ010 REQ011 User Story - Backlog Item System shall have fields for firstname, middle initial and last name System shall display a name if there is one in the stored profile System shall require name is completed System shall have a field for position or title System shall require title is completed System shall display a position or title if there is one in the stored profile System shall have a field for email address System shall have a field for alternate email address System shall display an email address if there is one in the stored profile System shall display an alternate email address if there is one in the stored profile System shall require email address is completed Requirement Engineering 16 2012.08 Requirements Activities in the System Life Cycle  Identifying the stakeholders  Gaining an understanding of the customers’ and users’ needs for the planned system and their expectations of it  Identifying requirements  Clarifying and restating the requirements  Analyzing the requirements  Defining the requirements in a way that means the same thing to all of the stakeholders Requirement Engineering 17 2012.08 Requirements Activities in the System Life Cycle  Specifying the requirements  Prioritizing the requirements  Deriving requirements  Partitioning requirements  Allocating requirements  Tracking requirements  Managing requirements  Testing and verifying requirements  Validating requirements Requirement Engineering 18 2012.08 Investment in the Requirements Process  2% - 3% of total project cost/effort  80% - 200% cost overrun  NASA:  8% - 14% of total project cost/effort  0% - 50% cost overrun Requirement Engineering 19 2012.08 Investment in the Requirements Process Requirement Engineering 20 2012.08 A Process Approach  great value to using a process approach     Those who support the activity document the actions or activities involved in getting something done Once documented, there is a common (shared) understanding of what is involved The documented process can be understood by all who are involved Those involved, having a common understanding, can suggest improvements to the process (enabling continuous improvement and empowering those who are involved to contribute ideas for making the process better) Requirement Engineering 21 2012.08 The Requirements Plan  should be developed by the RA early   proposal preparation phase proceed with a development project or task  The purpose of the requirements plan is to determine and document how Requirement Engineering 22 The Requirements Plan: 2012.08 topics  Purpose  Contract/project summary  vision and scope  Background  describe the situation that led to the decision to develop the system (major stakeholder groups)  Evolution of the requirements  to review the stated requirements and evolve the real requirements Requirement Engineering 23 The Requirements Plan: 2012.08 topics  Roles and responsibilities of the project’s personnel involved in requirements-related activities  Definition of the requirements process to be used  Mechanisms, methods, techniques, and tools to be utilized  Integration of proven effective requirements practices Requirement Engineering 24 The Requirements Plan: 2012.08 topics  References  set of documents that are key references for the requirements process  Recommended strategy  Appendixes Requirement Engineering 25 2012.08 Factors Affecting Your Career Decisions  meet with a PM very early, perhaps even before an assignment to the project is finalized Discuss with him or her perspectives concerning requirements  can be effective in your role ! Requirement Engineering 26 2012.08 A Comment Concerning Small Projects  can be used to scale down and apply key practices to achieve good results on small projects Requirement Engineering 27 2012.08 Criteria of a Good Requirement Consistent If the system can meet prioritized real needs without the requirement, it isn’t necessary The requirement is doable and can be accomplished within budget and schedule The facts related to the requirement are accurate, and it is technically and legally possible The requirement is stated simply The requirement can be interpreted in only one way All conditions under which the requirement applies are stated, and it expresses a whole idea or statement It is not in conflict with other requirements Verifiable Implementation of the requirement in the system can be proved Necessary Feasible Correct Concise Unambiguous Complete [1] chapter 01, p008 Requirement Engineering 28 2012.08 Criteria of a Good Requirement The source of the requirement can be traced, and it can be Traceable tracked throughout the system (e.g., to the design, code, test, and documentation) The requirement is assigned to a component of the designed Allocated system Design independent It does not pose a specific implementation solution Nonredundant It is not a duplicate requirement Written using the standard construct The requirement is stated as an imperative using “shall.” Assigned a unique identifier Each requirement shall have a unique identifying number Language should not include such phrases as “if,” “when,” “but,” “except,” “unless,” and “although.” Language should not be Devoid of escape clauses speculative or general (i.e., avoid wording such as “usually,” “generally,” “often,” “normally,” and “typically”) [1] chapter 01, p008 Requirement Engineering 29 2012.08 Case Study the top reasons that were reported by a set of PMs The requirements for the project are not explicit Requirements changes are made/accepted without addressing the concomitant cost, schedule, and quality impacts A requirements process is not used There is no mechanism (such as a joint team) to reach agreement on the definition of the requirements and to manage the requirements through the project life cycle The “real” customer needs are not defined There is no mechanism to maintain communication between the parties involved in the project Known, familiar, proven methods, techniques, and tools are not utilized The customer is not involved as a partner throughout the project life cycle WHAT will help overcome these problems ? Requirement Engineering 30 2012.08 Q/A ?! Requirement Engineering ... requirements  the real requirements of customers [1] chapter 01, p0 01 Requirement Engineering 2 012 .08 Requirement Engineering 2 012 .08 Requirement Engineering 2 012 .08 Outline  What are Requirements and... work (SOW) Requirement Engineering 10 2 012 .08 Ex A long list of requirements REQ ID REQ0 01 REQ002 REQ003 REQ004 REQ005 REQ006 REQ007 REQ008 REQ009 REQ 010 REQ 011 User Story - Backlog Item System... Requirement Engineering 12 2 012 .08 “Limitations of the Human Brain”  Miller’s Magic Number Visual Models for Software Requirements [p04] Requirement Engineering 13 2 012 .08 Why plan ?  are familiar