1 / 183

Requirements Engineering

Requirements Engineering. Southern Methodist University CSE 7316 – Framing the Problem. Understanding the problem domain. Requirements and Design Patterns. Orderly engineering starts with some type of design pattern we know we want a bridge

norberts
Download Presentation

Requirements Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. RequirementsEngineering Southern Methodist University CSE 7316 – Framing the Problem

  2. Understanding the problem domain

  3. Requirements and Design Patterns • Orderly engineering starts with some type of design pattern • we know we want a bridge • Rigorous research and definition of requirements is possible only in relation to a specific design pattern • what type of traffic to carry, auto and/or pedestrians, etc

  4. Requirements and Design Patterns • A ferry solution would pose an entirely different set of questions • That’s why you cannot get too detailed in specifying what you want - you limit the solution space • Common complaint from customers, programmers, testers, etc • “Requirements are so abstract that nobody can understand them”

  5. Requirements and Design Patterns • Corresponding to every design pattern is a set of questions to ask about the problem that the pattern solves. A requirements document answers these questions. • Writing requirements answers a specific set of questions • should be precise enough to allow the engineer to apply the pattern to create a new design

  6. Software Problems • All software problems are of this form: “Configure machine M to produce effects R in domain D.” M = computer to be programmed R = the requirements D = part of the world in terms of which the requirements are defined.

  7. Software Problems • Fundamental questions to answer when writing software requirements; • what type of machine do you want configured? • what effects do you want the configuration to produce? • what are the properties of the outside world that the machine can exploit to produce those effects?

  8. The information problem • The task of the s/w developer is to configure the computer into an information system (combination of h/w and s/w) to supply information about the state of some part of the world • Questions to answer; • 1. what machine is to be configured to act as the information server?

  9. The information problem • 2. what questions can the user ask of the information system? • 3. what part of the world do these questions concern and what events happen there? • 4. how can the machine get access to these events? • (2) provides the requirements • (3) and (4) provide info about the domain • (1) usually fades into the background

  10. Requirements Engineering • Requirements are the desired effect • Interfaces, program code, etc are the means to bring it about • Requirements engineering • the design of requirements • most critical part of many projects • the desired effects - someone has to think of these desired effects

  11. Requirements Engineering • Software quality is not just meeting the requirements • Software fails many time because people refused to buy or use the software because • the problem that it solved was of no concern to them • they preferred to leave that problem unsolved • Requirements can be of low quality!

  12. Requirements Engineering • There are many ways of meeting requirements • user interface solutions take on many forms • What makes requirements different from design • defines a problem such that we can say that the interfaces and program code either solve it or fail to solve it

  13. Requirements Engineering • Inventing requirements is a matter of inventing a well defined problem to solve • Well-defined problem; a set of criteria according to which proposed solutions either definitely solve the problem or definitely fail to solve it, along with any ancillary information, such as which materials are available to solve the problem.

  14. Requirements Engineering • Must design against an open-ended problem • Open-ended problem; a situation in which we believe that some improvement is possible, but we have no definite criteria for measuring improvement. Discovering new criteria is, itself, part of the problem.

  15. Requirements Engineering • Options to building a bridge • dig a tunnel • widen existing roads • narrow existing roads (people stop driving and move closer -> culture changes….) • What is the requirement? to make traffic move faster? to get people to work faster?

  16. Requirements Engineering • All engineering begins with open-ended problems • no requirements - just the belief that improvement is possible • Two common mistakes • settling on strict evaluation criteria too early • writing requirements so vaguely that they don’t define any requirements at all

  17. Requirements Engineering • Requirements engineering starts with an open-ended problem and finish with a well-defined problem • If you haven’t made the decision to write software, you are not ready to hand the problem off to software engineers -> you are still doing requirements

  18. Summary • Generalized problem solving methods don’t work , at least not well enough to base a method of requirements-writing on them • Do not try to document an entire open-ended problem in a requirements document

  19. Summary • Tailor the information in requirements documents to specific kinds of software and specific known design patterns and programming techniques • Provide information about specific events in domain D

  20. The Problem Domain

  21. The Problem Domain • Requirements define the problem to be solved by the software; they do not describe the software that solves it • customers rarely specify software behavior • more interested in problem domain • Problem domain; part of the world where the computer is to produce desired effects; and the means to produce them

  22. The Problem Domain • Indirect means • users whom the computer can do tasks with • motors that can be turned on and off • people or other machines to supply information • Direct means • behavior of I/O devices • keyboards • screens • printers

  23. The Problem Domain • Problem domain is not just the world outside the computer • without knowledge of the I/O devices the problem becomes abstract • sometimes the problem domain does not exist outside the computer • word processor • CAD program • these programs create the problem domain

  24. The Problem Domain • requirements are specifically for the I/O devices to behave a certain way

  25. Requirements • Requirement; the effects that the computer is to exert in the problem domain, by virtue of the computer’s programming • what the customer wants to achieve in the problem domain • truck, cargo, driver, road are all objects in a problem domain

  26. Software Designs • Three principle designs • design of the requirements • design of the interfaces that bring about the requirements • design of the program that makes the computer behave as specified by the interface design

  27. Two worlds Problem domain Machine domain Pick up cargos Database schemas subroutines interfaces Haul cargos to destinations Linked lists Print reports Specification Program Three designs Requirements

  28. Validation of Interfaces and Programs • It should always be possible to prove the validity of the interface design on the basis of the description of the problem domain plus the requirements

  29. Validation of an interface design • Premises: • the behavior described in the I/F design occurs • the computers environment matches the description of the problem domain • Conclusion • the requirements are fulfilled • If the conclusion does not follow from the premises, the I/F design is invalid

  30. Validation of a Program • Premises; • the program consists of specified instructions • the platform on which the program runs possesses the specified library, OS, H/W • Conclusion • the behavior described in the I/F design occurs

  31. More simply put.. • A program is validated against a specification • A specification is validated against requirements and the problem domain • Therefore • without requirements there is no way to validate a program design (to connect the program to the customers desires)

  32. Requirements • Writing down requirements is a device to help people work together on the same project • Requirements; designed in response to an open-ended problem • Interface design; derives from a well defined problem (provided by requirements)

  33. Types of information in a problem domain description

  34. Problem Domain Description • Software designers need knowledge of the problem domain • requirements or descriptive statements are not enough • well written requirements document contain more information about the problem domain than requirements statements • Requirements document must describe the problem domain in sufficient detail

  35. Evolving the requirements • Impossible to write excellent requirements at the beginning of a complex project • evolves from our knowledge of interfaces and programming • incrementally developed software • Two strategies • start with sketchy requirements and add detail at each stage • spiral approach

  36. NASA Space Program • Strategy of rigorously solving a series of progressively more complex problems • Goal: Land a man on the moon and return him safely to the earth • far too ambitious to attempt all at once • numerous complete spacecraft were designed and launched for the purpose of learning about various problems with space flight

  37. NASA Space Program • Project Mercury; solved problems of orbital dynamics and human life support in space • Project Gemini; solved problems of extravehicular activity and space docking • Project Apollo; solved the final problems of landing a man on moon and returning • Each experience improved the requirements for the next design

  38. What software requirements are not • Not top-down • mainly concerned with the program and not the problem domain • Not sketches • may be too abstract - no well defined problem • Not what versus How • everything in engineering is what and everything is how

  39. Problem Framing

  40. Knights Tour - Before

  41. Knights Tour - After

  42. Framing the Problem • First step in documenting software requirements is to frame the problem • definite form • definite parts • definite relations between the parts • Makes the details fit into a systematic framework to be analyzed without becoming overwhelmed

  43. Domains • Each domain contains a set of individuals • distinguishable things about which we want to make a statement • trucks, cargo, drivers, etc • the physical part of the world • subroutines, data structures, I/O • potential individuals; customers • Individuals are distinguishable from each other

  44. Separation into Domains Machine domain Problem domain Pick up cargos Database schemas subroutines interfaces Haul cargos to destinations Linked lists Print reports Specification Program Requirements

  45. Domains • Domains also contain everything we want to say about the individuals • truck is now carrying the cargo • predicate; everything we want to be able to assert or deny • one subroutine calls another

  46. Domain Framing • Statements made about the problem domain must address individuals within the problem domain only • requirements documents address issues in the problem domain • cannot address issues in the machine domain

  47. Types of Domain Information • What types of entities can be in the domain? • What attributes should those entities have? • Relationships between entities • Types of events that can occur in the domain • The causal law according to which the entities behave • motor A is on iff bit 7 of I/O port is high...

  48. Types of Domain Information • Events treated as individuals • attributes are entities that participated in the event • relations are things like before and after • Information then incorporated into propositions; assertions or denials that certain individuals possess certain attributes or bear certain relations to each other

  49. Mathematics • Individuals and predicates • relations between propositions • attributes • This is a form of predicate and propositional calculus • Also a natural language form • The tricky part is to decide what individuals to talk about and what predicates to use

More Related