Requirement Engineering


Published on

Published in: Engineering, Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Requirement Engineering

  1. 1. 1211501075 – Christian Yonathan Sillueta
  2. 2. Overview • Describe requirement engineering activities and processes. • Look into techniques, problems, challenges of: – Feasibility Studies – Requirements elicitation – Requirement specification – Requirements Validation – Requirements management and evolution
  3. 3. Importance of Requirements • Making design decisions without understanding all the constraints on the system to be developed results in a system which fails to meet customer’s expectations • Costs of correcting errors increases as the design process advances. • An error detected in the maintenance phase is 20 times as costly to fix as an error detected in the coding stage.
  4. 4. Cumulative effects of error
  5. 5. The Basics • A requirement mandates that something be accomplished, transformed, produced or provided • Requirements engineering is the discipline concerned with understanding the externally imposed conditions on a proposed computer system, determining what capabilities will meet these imposed conditions and and documenting those capabilities as the software requirements for the computer system.
  6. 6. Requirements Engineering Process • The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements Requirements Elicitation Requirements Analysis Requirements Specification Requirements Verification Requirements Management Requirements Engineering Requirements Elicitation Requirements Analysis Requirements Specification Requirements Verification Requirements Management Requirements Engineering
  7. 7. Requirements Engineering Process • Requirements elicitation : The process through which clients and developers review, articulate and understand the needs of the clients and the constraints on the software • requires involvement with the client, domain experts, and end-users in order to establish an the client’s needs and the constraints on the system. Here we use techniques such as: (1) Interviews, (2) Questionnaires, (3) Focus groups, (4) Apprenticing, and (5) modelling.
  8. 8. Requirements Engineering Process • Requirements Analysis : The process of analysing the needs of the clients in order to arrive at a definition of the requirements • aims to deepen our understanding of the constraints and client needs • Requirements Specification : The process by which a document is developed which clearly communicates the requirements. • The requirements are captured, or expressed, or articulated, in a software requirements specification.
  9. 9. Requirements Engineering Process • Requirements Validation : The process of ensuring that the requirements and the Software Requirements Specification are in compliance with the needs of the clients and the system • techniques here include (1) reviews, inspections and walkthroughs of requirements, and (2)prototyping. • Requirements Management and evolution : The planning and controlling of the requirements engineering processes. Requirements specification should evolve with time.
  10. 10. Feasibility Study
  11. 11. Feasibility • Feasibility studies aim to objectively and rationally – Uncover the strengths and weaknesses of the existing business or proposed venture – Opportunities and threats as presented by the environment. – The resources required to carry through. – Ultimately the prospects for success of the proposition • In its simplest term, the two criteria to judge feasibility are cost required and value to be attained.
  12. 12. Types of Feasibility • The assessment is based on an outline design of system requirements in terms of Input, Processes, Output, Fields, Programs, and Procedures. • Technological feasibility – carried out to determine whether the company has the capability, in terms of software, hardware, personnel and expertise, to handle the completion of the project – when writing a feasibility report, the following should be taken to consideration: • A brief description of the business • The part of the business being examined • The human and economic factor • The possible solutions to the problems
  13. 13. Types of Feasibility • Economic analysis used method for evaluating the effectiveness of a new system. More commonly known as cost/benefit analysis, the procedure is to determine the benefits and savings that are expected from a candidate system and compare them with costs. If benefits outweigh costs, then the decision is made to design and implement the system. Cost-based study: It is important to identify cost and benefit factors, which can be categorized as follows: 1. Development costs 2. Operating costs. This is an analysis of the costs to be incurred in the system and the benefits derivable out of the system. Time-based study: This is an analysis of the time required to achieve a return on investments. The future value of a project is also a factor.
  14. 14. Types of Feasibility • Legal feasibility Determines whether the proposed system conflicts with legal requirements, e.g. data processing system must comply with the local Data Protection Acts. • Operational feasibility Operational feasibility is a measure of how well a proposed system solves the problems, and takes advantage of the opportunities identified during scope definition and how it satisfies the requirements identified in the requirements analysis phase of system development. • Schedule feasibility A project will fail if it takes too long to be completed before it is useful. Typically this means estimating how long the system will take to develop, and if it can be completed in a given time period using some methods like payback period. Schedule feasibility is a measure of how reasonable the project timetable is. You need to determine whether the deadlines are mandatory or desirable.
  15. 15. Types of Feasibility • Financial feasibility In case of a new project, financial viability can be judged on the following parameters: – Total estimated cost of the project – Financing of the project in terms of its capital structure, debt equity ratio and promoter's share of total cost – Existing investment by the promoter in any other business – Projected cash flow and profitability • Other feasibility factors: – Market and real estate feasibility – Resource feasibility – Cultural feasibility
  16. 16. Requirements Elicitation
  17. 17. • Requirements Elicitation is the process of discovering the requirements for a system by communication with customers, system users and others who have a stake in the system development. Elicitation
  18. 18. • The “Yes, But” syndrome • The Undiscovered Ruins • “User and Developer” syndrome • “The sins of your predecessors” Challenges of Requirements Elicitation
  19. 19. The “Yes, But” syndrome • First time users see the system the first reaction is either, “wow this is so cool” or “Yes, but, hmmmmm, now that I see it, what about this…? Wouldn’t it be nice …? • Anticipate that there will be “yes, buts” and add time and resources to plan for feedback. • Tends to be User Interface centric, these tend to be the touch points of the system by the users.
  20. 20. The “Undiscovered Ruins” syndrome Teams struggle with determining when they are done with requirements elicitation. – Is done when all the requirements are elicited or have they found at least enough? – Like asking an archeologist “how many undiscovered ruins are there?”
  21. 21. The “User and the developer” syndrome • Users do not know what they want, or they know what they want but cannot articulate it. • Users think they know what they want until developers give them what they said they wanted. • Analysts think they understand user problems better than users do. • Recognize and appreciate the user as domain experts; try different techniques. • Provide alternative elicitation techniques earlier; storyboard, role playing, prototypes, and so on. • Put the analyst in the users place. Try role playing for an hour or a day. CharacteristicCharacteristic ResponseResponse
  22. 22. The “living with the sins of your predecessors” syndrome • Like it or not your users (marketing) and developers remember what happened in the past. – Quality programs that promised things would be different. – The last project where requirements were vague and/or were delivered short of expectations. • Need to build trust, slowly. Do not over commit to features, schedule, or budget. • Build success by delivering highest priority features early in the process.
  23. 23. The Requirements Elicitation techniques • Interviewing and questionnaires • Requirements workshops • Braining Storming and idea reduction • Use Cases • Role Playing • Prototyping EX: Summary
  24. 24. Interview : Context Free Question • Goal is to prevent prejudicing the user’s response to the questions. • Examples: – Who is the user? – Who is the customer? – Are their needs different? – Where else can a solution to this problem be found? • Context-free questions • After context-free questions are asked, suggested solutions can be explored.
  25. 25. Interview : Show Time • Establish Customer or User Profile • Assessing the Problem • Understanding the User Environment • Recap the Understanding • Analyst’s Inputs on Customer’s Problems • Assessing Your Solution (if applicable)
  26. 26. Technique : Requirement workshop • It gathers all key stakeholders together for a short but intensely focused period. • The use of an outside facilitator experienced in requirements management can ensure the success of the workshop. • Brainstorming is the most important part of the workshop.
  27. 27. Technique : Role Playing – variant on use cases • Role playing allows stakeholders to experience the user’s world from the user’s perspective. • A scripted walkthrough may replace role playing in some situations, with the script becoming a live storyboard. (Class-Responsibility-Collaboration (CRC) cards, often used in object-oriented analysis, are a derivative of role playing.)
  28. 28. Requirements Analysis & Specification
  29. 29. Analysis & Specification • Requirements analysis : The process of studying and analysing the customer and the user/stakeholder needs to arrive at a definition of software requirements • Requirements Specification: o A document that clearly and precisely describes essential requirements of software and external interfaces (functions, performance, quality etc.) o each requirement is specified such that its achievement is capable of being verified by a prescribed method like inspection, test.
  30. 30. Analysis of Elicitation Results Analysis of the results of elicitation process helps to create a better vision of the product and its specification by: • Explaining the problem statement better • Marketing group establishes positioning of the product • Stakeholder and user summaries o user is special case of stakeholder o identify stakeholder w.r.t development o identify stakeholder w.r.t system
  31. 31. • The precision to which Requirements are specified is a function of • Expertise of developers • Knowledge developers and testers have of the domain – the more they know, the less specific the specification needs to be • Access to a domain representative • For example, in xp, requirements may be specified in less detail but there is a customer representative on site daily. Requirement Specification
  32. 32. Requirements Perspectives • User requirements – Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. • System requirements – A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor.
  33. 33. Types of Requirements • Functional requirements : Statements of services, how the system should react to particular inputs, what functionalities is to be provided. Functional requirements are not concerned with how these functions are to be achieved, just what is to be achieved. • Non – functional requirements: deals with attributes, or properties, of the software rather than functions. We include here aspects of the software such as its performance, its usability, its reliability, any safety aspects and a range of other attributes. • Domain Requirements: Requirements of the application domain of the system, reflect characteristics of that domain.
  34. 34. Requirements Characteristics • Unambiguous • Testable (verifiable) • Clear (Concise, terse, simple, precise) • Correct • Understandable • Feasible • Independent • Atomic • Necessary • Implementation – free (abstract)
  35. 35. Requirements Characteristics Besides the criteria for individual requirements, 3 criteria should apply to the set of requirements as a whole: • Consistent • Non redundant • Complete
  36. 36. The Output A Software Requirements Specification (SRS) – A formal Document as the OUTPUT of the Specification stage. it is a complete description of the behavior of a system to be developed. INCLUDES: Functional Requirements Non- Functional Requirements Constraints Design Strategy Quality and Standards Architecture Development Methodology
  37. 37. Sequence Diagram ATM Database Card Card number Card OK PIN request PIN Option menu <<exception>> invalid card Withdraw request Amount request Amount Balance request Balance <<exception>> insufficient cash Debit (amount) Debit response Card Card removed Cash Cash removed Receipt Validate card Handle request Complete transaction
  38. 38. Activity Diagram
  39. 39. Data Flow Diagram
  40. 40. Validation
  41. 41. Requirements Validation Validation: ensures that the software being developed will satisfy it stakeholders – Requirements Validation checks the software requirements specification against stakeholders goals and requirements Verification: ensures that each step followed in the process of building the soft ware yields the right products – Requirements Verification checks the consistency of the software requirements specification artifacts and other Software development products (design, implementation, ...) again st the specification
  42. 42. Typical Requirements V&V approaches • Tracing approaches • Prototyping • Testing • User manual writing • Formal validation • Reviews and inspections • Walkthroughs • Formal inspections • Checklists
  43. 43. Requirements Management and Evolution
  44. 44. Definition Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. A requirement is a capability to which a project outcome (product or service) should conform.
  45. 45. Requirements Pyramid
  46. 46. CASE Tools IBM Rational DOORS® Requirements management, traceability, and impact analysis capabilities for more formal, rigorous requirements engineering purposes, primarily suited to organizations creating manufactured systems and products IBM Rational Requirements Composer Helps teams to define requirements more effectively and manage them efficiently across the project lifecycle to gain better business outcomes through light-weight requirements practices IBM Rational RequisitePro® Requirements management, traceability, and impact analysis capabilities for project teams, primarily suited to organizations creating application software
  47. 47. Software Evolution • The priority of requirements from different viewpoints changes during the development process. • System customers may specify requirements from a business perspective that conflict with end-user requirements. • The business and technical environment of the system changes during its development.
  48. 48. Classification for changing requirement • Enduring requirements. Stable requirements derived from the core activity of the customer organisation. • Volatile requirements. Requirements which change during development or when the system is in use.
  49. 49. Classification for changing requirement • Enduring requirements. Stable requirements derived from the core activity of the customer organisation. • Volatile requirements. Requirements which change during development or when the system is in use.
  50. 50. Requirements Traceability Requirements traceability is concerned with documenting the life of a requirement. It should be possible to trace back to the origin of each requirement and Every change made to the requirement should therefore be documented in order to achieve traceability. Even the use of the requirement after the implemented features have been deployed and used should be traceable[4].