Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements

Transcription

1 Questions? Assignment Why is proper project management important? What is goal of domain analysis? What is the difference between functional and non- functional requirements? Why is it important for requirements to be testable? EAssign.pdf Online!!! Deadline: 31 st of October 2011 / Faculteit Wiskunde en Informatica PAGE 0 / Faculteit Wiskunde en Informatica PAGE 1 Techniques for Gathering Requirements Gathering and Analysing Requirements Observation Read documents and discuss requirements with users Shadowing important potential users as they do their work Session video recording Interviewing Conduct a series of interviews Ask about specific details Ask about the stakeholder s vision for the future Ask if they have alternative ideas Ask for other sources of information Ask them to draw diagrams Brainstorming Prototyping The simplest kind: paper prototype. a set of pictures of the system that are shown to users in sequence to explain what would happen The most common: a mock-up of the system s UI Written in a rapid prototyping language Does not normally perform any computations, access any databases or interact with any other systems May prototype a particular aspect of the system / Faculteit Wiskunde en Informatica PAGE 2 / Faculteit Wiskunde en Informatica PAGE 3

2 Gathering and Analysing Requirements Level of detail required in a requirements document Use case analysis Determine the classes of users that will use the facilities of this system (actors) Determine the tasks that each actor will need to do with the system How much detail should be provided depends on: size of the system need to interface to other systems readership stage in requirements gathering level of experience with the domain and the technology cost that would be incurred if the requirements were faulty / Faculteit Wiskunde en Informatica PAGE 4 / Faculteit Wiskunde en Informatica PAGE 5 Representation of requirements Reviewing Requirements Each individual requirement should Have benefits that outweigh the costs of development Be important for the solution of the current problem Be expressed using a clear and consistent notation Be unambiguous Be logically consistent Lead to a system of sufficient quality Be realistic with available resources Be verifiable Be uniquely identifiable Does not over-constrain the design of the system / Faculteit Wiskunde en Informatica PAGE 6 / Faculteit Wiskunde en Informatica PAGE 7

3 Requirements Review Checklist Requirements Review Checklist (cont.) 1. Does each user requirement have a unique identifier? 2. Is each user requirement atomic and simply formulated? (Single sentence. Composite requirements can best be split.) 3. Are user requirements organized into coherent groups? (If necessary, hierarchical; not more than about ten per group.) 4. Is each user requirement verifiable (in a provisional acceptance test)? (Where possible, quantify.) 5. Is each user requirement prioritized? 6. Are all unstable user requirements marked as such? (TBC=`To Be Confirmed') 7. Are all user requirements necessary? 8. Are the user requirements complete? Can everything not explicitly constrained indeed be viewed as developer freedom? Is a product that satisfies every requirement indeed acceptable? (No requirements missing.) 9. Are the user requirements consistent? (Non-conflicting.) 10. Are the user requirements sufficiently precise and unambiguous? (Which interfaces are involved, who has the initiative, who supplies what data; avoid passive voice.) 11. Are the user requirements understandable to those who will need to work with them later? 12. Are the user requirements realizable within budget? / Faculteit Wiskunde en Informatica PAGE 8 / Faculteit Wiskunde en Informatica PAGE 9 Requirements Review Checklist (cont.) Requirements Review Checklist (cont.) 13. Do the user requirements express actual customer needs (in the language of the problem domain), rather than solutions (in developer jargon)? 14. Are the user requirements not overly restrictive? (Allow enough developer freedom.) 15. Is overlap among user requirements pointed out explicitly? (Redundancy; cross-reference.) 16. Are dependencies between user requirements pointed out explicitly? Are these consistent with the priorities? 17. Are the characteristics of users and of typical usage described in sufficient detail? (No user categories missing.) 18. Is the operational environment described in sufficient detail, including e.g. relevant data flows in the "outside" world that do not interact directly with the system? (No external interfaces missing. No capabilities missing. Diagram included.) / Faculteit Wiskunde en Informatica PAGE 10 / Faculteit Wiskunde en Informatica PAGE 11

4 Requirements documents Managing Changing Requirements The document should be: sufficiently complete well organized clear agreed to by all the stakeholders Traceability: Requirements change because: Business process changes Technology changes The problem becomes better understood rationale Requirements document 1.11 XXXX... because 1.2 YYYY Design document...due to requirement 1.2 / Faculteit Wiskunde en Informatica PAGE 12 / Faculteit Wiskunde en Informatica PAGE 13 Managing Changing Requirements V model for software development Requirements analysis never stops Continue to interact t with the clients and users The benefits of changes must outweigh the costs. Certain small changes (e.g. look and feel of the UI) are usually quick and easy to make at relatively little cost. Larger-scale changes have to be carefully assessed Forcing unexpected changes into a partially built system will probably result in a poor design and late delivery Some changes are enhancements in disguise Avoid making the system bigger, only make it better / Faculteit Wiskunde en Informatica PAGE 14 / Faculteit Wiskunde en Informatica PAGE 15

5 The Process of Design Design as a series of decisions Definition: Design is a problem-solving process whose objective is to find and describe a way: To implement the system s functional requirements... While respecting the constraints imposed by the quality, platform and process requirements... including the budget And while adhering to general principles of good quality A designer is faced with a series of design issues These are sub-problems of the overall design problem Each issue normally has several alternative solutions: design options: software vs hardware The designer makes a design decision to resolve each issue This process involves choosing the best option from the alternatives / Faculteit Wiskunde en Informatica PAGE 16 / Faculteit Wiskunde en Informatica PAGE 17 Making decisions From requirements to implementation To make each design decision, the software engineer uses: Knowledge of the requirements the design as created so far the technology available software design principles and best practices what has worked well in the past System: A logical entity, having a set of definable responsibilities or objectives, and consisting of hardware, software or both. A system can have a specification which is then implemented by a collection of components. A system continues to exist, even if its components are changed or replaced. The goal of requirements analysis is to determine the responsibilities of a system. Subsystem: A system that is part of a larger system, and which has a definite interface / Faculteit Wiskunde en Informatica PAGE 18 / Faculteit Wiskunde en Informatica PAGE 19

6 From requirements to implementation From requirements to implementation Component: Any piece of software or hardware that has a clear role A component can be isolated, allowing you to replace it with a different component that has equivalent functionality Many components are designed to be reusable Conversely, others perform special-purpose functions Module: A component that is defined at programming language level For example: classes and packages are modules in Java Function: Unit at programming level with specific behaviour For example: methods in Java, functions in C / Faculteit Wiskunde en Informatica PAGE 20 / Faculteit Wiskunde en Informatica PAGE 21 Top-down and bottom-up design Top-down and bottom-up design Top-down design First design the very high level structure of the system Then gradually work down to detailed decisions about low- level constructs Finally arrive at detailed decisions such as: the format of particular data items; the individual algorithms that will be used Bottom-up design Make decisions about reusable low-level utilities Then decide how these will be put together to create high- level constructs A mix of top-down and bottom-up approaches are normally used: Top-down design is almost always needed to give the system a good structure Bottom-up design is normally useful so that reusable components can be created / Faculteit Wiskunde en Informatica PAGE 22 / Faculteit Wiskunde en Informatica PAGE 23

7 Different aspects of design UML and SysML Architecture design: The division into subsystems and components, How these will be connected How they will interact Their interfaces. Class design: The various features of classes User interface design Algorithm design: The design of computational mechanisms Protocol design: The design of communications protocol Based on the slides of Professor Insup Lee (University of Pennsylvania) / Faculteit Wiskunde en Informatica PAGE 24 / Faculteit Wiskunde en Informatica PAGE 25 The Unified Modeling Language g (UML) is A standard language for specifying, visualizing, constructing and documenting the artifacts of software systems, as well as for business modeling and other non-software systems The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems Six diagram types represent static application structure: Class Diagram Object Diagram Component Diagram Composite Structure Diagram Package Diagram Deployment Diagram / Faculteit Wiskunde en Informatica PAGE 26 / Faculteit Wiskunde en Informatica PAGE 27

8 Three diagram types represent general types of behavior: Use Case Diagram Activity Diagram State Machine Diagram Four diagram types represent different aspects of interactions Sequence Diagram Interaction Overview Diagram Communication Diagram Timing Diagram / Faculteit Wiskunde en Informatica PAGE 28 / Faculteit Wiskunde en Informatica PAGE 29 UML2 Super structure specification Structure diagrams: Class diagram Class diagram shows the relationships between the various classes in the System.The Classes being identified using the OOD paradigm. It s a static diagram and hence does not show the way in which the interaction happens. association -- an instance of one class must know about the other in order to perform its work. ( ) aggregation -- an association in which one class belongs to a collection. ( ) composition -- an association in which one class is composed of other classes.( ) generalization -- an inheritance link indicating one class is a superclass of the other. ( ) / Faculteit Wiskunde en Informatica PAGE 30 / Faculteit Wiskunde en Informatica PAGE 31

9 Structure diagrams: Class diagram Structure diagrams: Object diagram The relationships is shown in terms of the instances created of the objects that we defined The various objects instantiated are shown as well the relationships between th bj t those objects / Faculteit Wiskunde en Informatica PAGE 32 / Faculteit Wiskunde en Informatica PAGE 33 Structure diagrams: Package diagram Package diagram shows the hierarchy in which the system will be modeled in the implementation It gives a high level view for the distribution that can be created within the ifi d j t d if th k i ibilit specified project and specify the package visibility Structure diagrams: Composite Structure diagram Composite Structure diagram reflects the internal collaboration of classes, interfaces or components to describe a functionality Composite Structure diagrams are similar to Class diagrams, except that they model a specific usage of the structure Composite Structure diagram is used to express run-time architectures, usage patterns, and the participating elements' relationships, which might not be reflected by static diagrams / Faculteit Wiskunde en Informatica PAGE 34 / Faculteit Wiskunde en Informatica PAGE 35

10 Structure diagrams: Composite Structure diagram Structure diagrams: Deployment diagram Deployment diagram shows how and where the system will be deployed. Physical machines and processors are reflected as nodes, and the internal construction can be depicted by embedding nodes or artifacts / Faculteit Wiskunde en Informatica PAGE 36 / Faculteit Wiskunde en Informatica PAGE 37 Structure diagrams: Component diagram Component diagram illustrates the pieces of software, embedded controllers, etc. that will make up a system. Component diagram has a higher level of abstraction than a Class diagram - usually a component is implemented by one or more classes (or objects) at runtime Behavior diagrams: Use case diagram Use cases diagram basically are a substitute of the requirements being Modeled into the architecture. The external viewpoint as to what the System should do rather how / Faculteit Wiskunde en Informatica PAGE 38 / Faculteit Wiskunde en Informatica PAGE 39

11 Behavior diagrams: Activity diagram Activity diagrams are used to model the behaviors of a system, and the way in which these behaviors are related in an overall flow of the system The logical paths a process follows, based on various conditions, concurrent processing, data access, interruptions and other logical path distinctions, are all used to construct a process, system or procedure Behavior diagrams: Activity diagram / Faculteit Wiskunde en Informatica PAGE 40 / Faculteit Wiskunde en Informatica PAGE 41 Behavior diagrams: State Machine diagram A State Machine diagram illustrates how an element, often a class, can move between states classifying its behavior, according to transition triggers, constraining guards and other aspects of State Machine diagrams that depict and explain movement and behavior Interaction diagrams: Sequence diagram Sequence diagram is an interaction diagram that details how operations are carried out -- what messages are sent and when Sequence diagrams are organized according to time expressed in the sequential order along the vertical plane / Faculteit Wiskunde en Informatica PAGE 42 / Faculteit Wiskunde en Informatica PAGE 43

12 Interaction diagrams: Sequence diagram Interaction diagrams: Communication/Collaboration diagram Communication diagram shows the interactions between elements at runtime in much the same manner as a Sequence diagram. Communication diagrams are used to visualize inter-object relationships, while Sequence diagrams are more effective at visualizing processing over time / Faculteit Wiskunde en Informatica PAGE 44 / Faculteit Wiskunde en Informatica PAGE 45 Interaction diagrams: Communication/Collaboration diagram Interaction diagrams: Timing diagram Timing diagram defines the behavior of different objects within a time-scale Provides a visual representation of objects changing state and interacting over time. Used for defining hardware-driven or embedded software components / Faculteit Wiskunde en Informatica PAGE 46 / Faculteit Wiskunde en Informatica PAGE 47

13 Interaction diagrams: Interaction Overview diagram Interaction Overview diagrams visualize the cooperation between other interaction diagrams to illustrate a control flow serving an encompassing purpose Interaction ti Overview diagrams are a variant of activity it diagrams, most of the diagram notation is similar, as is the process in constructing the diagram Interaction elements display an inline Interaction diagram, which can be a Sequence diagram, Communication diagram, Timing diagram, or Interaction Overview diagrams Interaction diagrams: Interaction Overview diagram / Faculteit Wiskunde en Informatica PAGE 48 / Faculteit Wiskunde en Informatica PAGE 49