Requirements Engineering College 1 PDF

Requirements Engineering College 1  Requirements Engineering  Boek: Mastering the Requirements Process – Suzanne Robertson, James Robertson › ISBN: 978-0-321-81574-3  Colleges: 18:00 – 21:15 › College 1: Hoofdstuk 1, 2 › College 2: Hoofdstuk 3, 4,...

Requirements Engineering College 1  Requirements Engineering  Boek: Mastering the Requirements Process – Suzanne Robertson, James Robertson › ISBN: 978-0-321-81574-3  Colleges: 18:00 – 21:15 › College 1: Hoofdstuk 1, 2 › College 2: Hoofdstuk 3, 4, 5, 6 › College 3: Hoofdstuk 10, 11, 12 › College 4: Hoofdstuk 13, 14, 15 › College 5: Hoofdstuk 16, 17 › College 6: Presentaties 2 Even voorstellen..  Jij: › Wie ben je? › Wat is je achtergrond (vorige opleiding)? › Waar werk je nu? Welke functie? › Welke studie en waarom deze studie? › Wat is (nu) je lievelingsaspect van de ICT? (Je zit hier niet aan vast, kan nog altijd veranderen!) › Wat wil je later worden/doen als je groot bent? (Je zit hier niet aan vast, kan nog altijd veranderen!) 3 6 Requirements Engineering Chapter 1: Some Fundamental Truths Fundamental Truth 1 Requirements are not really about requirements › The requirements activity is not principally about writing a requirements document › In stead, it focuses on understanding  A business problem  Providing a solution for the business problem › The real art of requirements discovery is discovering the real problem › Then identifying and choosing between alternative solutions 7 Effective way to build a product  Correctly understand: › What the product has to do › How it will be used › By whom it will be used › How it fits into the larger picture of the organization  A requirement is something the system is capable of doing or a property that the system must have.  The requirements must be discovered and specified before starting to build the product. 8 Fundamental Truth 2 If we must build software, then it must be optimally valuable for its owner › To be optimally valuable, the product must provide a benefit that is in proportion to the cost of the product › Owner:  The person or organization that pays for the software (or hardware or any other product you might be building)  The role of the requirements discoverer - call him a “business analyst,” “requirements engineer,” “product owner,” “systems analyst,” or any other title - is to determine what the owner values.  Understanding the owner’s problem well enough to deliver a 9 Fundamental Truth 3  If your software does not have to satisfy a need, then you can build anything. However, if it is meant to satisfy a need, then you have to know what that need is to build the right software 10 Fundamental Truth 4 There is an important difference between building a piece of software and solving a business problem. The former does not necessarily accomplish the latter › Software is there to solve a business problem.  Any development effort must start with the problem, and not with a perceived solution. 11 Fundamental Truth 5  The requirements do not have to be written, but they have to become known to the builders › In some cases it is more effective to verbally communicate requirements; in other cases there is an inescapable need for a permanent record of the requirements. › In many cases the act of writing a requirement helps both the business analyst and the stakeholder to completely understand it. › Correctly written requirement provides trace documentation. › Rationale of a requirement, or the justification on a story card, documents the team’s decisions. › Also provides the testers and the developers with a clear indication of the importance of the requirement, which in turn suggests how much effort to expend on it. › Additionally, the cost of future maintenance is reduced when the 1 Fundamental Truth 7 Requirements do not come about by chance. There needs to be some kind of orderly process for developing them. › Orderly processes comprise a set of tasks that achieve the intended result, but leave the order, emphasis, and degree of application to the person or team using the process. › Most importantly, the people who are active in the process must be able to see why different tasks within the process are important, and which tasks carry the most significance for their project. 13 Fundamental Truth 8 You can be as iterative as you want (in the development), but you still need to understand what the business needs. 15 Fundamental Truth 9 There is no silver bullet. All our methods and tools will not compensate for poor thought and poor workmanship. 16 Fundamental Truth 10 Requirements, if they are to be implemented successfully, must be measurable and testable. › A functional requirement is something that your product must do to support its owner’s business. › A non-functional requirement is the quantification of how well it must carry out its functionality for it to be successful within the owner’s environment. › You must be precise when writing requirements.  At the same time, you must take into account the fact that requirements come from humans, and humans are not always, sometimes never, precise  To achieve necessary level of precision, you have to measure the requirement  If you can measure with numbers instead of words, you can make the requirement testable 1 Fundamental Truth 11 You, the business analyst, will change the way the user thinks about his problem, either now or later. › Once people have a better understanding of the real meaning of their requirements, they are likely to see ways of improving them. › Part of your job is to help people, as early as possible, to understand and question their requirements so that they can help you to discover what they really need. 18 What are requirements  Requirement: › Something the product must do to support its owner’s business › Or a quality it must have to make it acceptable and attractive to the owner › A requirement exists either because the type of product demands certain functions and qualities, or because the client justifiably asks for that requirement to be part of the delivered product. 19 What are requirements  Requirement: › Something a product must do or a quality it must have. › Pure state of business needs, without any implementation bias. › The role of product design is to translate the requirements into a plan to build some physical reality that will, in the real world, do what is needed.  Requirements expression › Usually as an abstraction, in a technologically neutral way.  As to intentionally avoid influencing the design of the solution. 20 Functional Requirements  A functional requirement describes an action that the product must take if it is to be useful to its operator— they arise from the work that your stakeholders need to do.  Functional Requirement › Things the product must do › Specify what the system must do › Actions the product must take › Derived from main goal of the product › Not a quality › Characterized by verbs 21 Non-functional Requirements  Non-functional requirements are properties, or qualities, that the product must have if it is to be acceptable to its owner and operator. › In some cases, non-functional requirements – these specify such properties as performance, look and feel, usability, security, and legal attributes – are critical to the product’s success. › Sometimes they are requirements because they enhance the product or make people want to buy it. › Sometimes they make the product usable › Properties, or qualities, that the system must have › Characterized by adjectives › Checklist: Look and feel, Usability, Performance Maintainability and Portability, etc 22 Constraints  Constraints are global (issues that shape the) requirements. They can be limitations on the project itself or restrictions on the eventual design of the product. › Constraints are global requirements. They can be limitations on the project itself or restrictions on the eventual design of the product. › Whatever they are constraining, constraints can be seen as another type of requirement › Global issues that shape the requirements. › They refer to any limitations on the way the product is produced › Design solution that must be used, availability of time and 2 Chapter 2: The Requirements Process a process for discovering requirements and how you might use it The Requirements Process  Whether you are building custom systems, building systems by assembling components, using commercial off-the-shelf software, accessing opensource software, outsourcing your development, or making changes to existing software, you still need to explore, discover, understand, and communicate the requirements. › If the right product is to be built, then the right requirements have to be discovered 25 The Volere Requirements Process  A process for successfully discovering, verifying, and documenting requirements. 26  Vragen? Hij/zij die een vraag stelt is 5 minuten dom; Hij/zij die geen vraag stelt is voor altijd dom Volere Requirements process › This map of the Volere Requirements Process shows the activities and their deliverables (stylized data flow notation)  Activities (the bubbles)  Activity deliverables (named arrows or documents)  Dotted lines represent how this process is used with iterative projects. 28 Huiswerk  Hoofdstuk 1 en 2 doornemen  Hoofdstuk 3, 4, 5 en 6 voorbereiden  Opdracht 1 29 Opdrachten Requirements Engineering algemeen  Vermeld je naam en studentnummer bij de opdracht  Gebruik naast het boek, goede (credible!) internet bronnen. › Vermeld alle bronnen die je gebruikt hebt. › Bij internet bronnen, datum van bezoek vermelden.  Idealiter, begin te oefenen met bronvermelding volgens APA (zie OFSS afstuderen map voor APA richtlijnen)  Geen copy paste van teksten (plagiaat!), gebruik je eigen woorden en zinnen in (correct! Spell checken en / of iemand voor je laten nalezen) Nederlands.  Sla je document op als: › _RE_Opdracht#_v# › (bv: RobertsonJ_RE_Opdracht3_v1.0)  Ik gebruik achter de punt versienummers (bv v1.4) voor mezelf en voor de punt versienummers (bv 2.0) om in te leveren.  Elke nieuwe versie krijgt steeds een hoger versienummer ++0.1 of + +1.0)  Deadline voor de opdrachten: Woensdag 23:59  Inleveren per mail bij [email protected] 30