IT313mid1.pdf

CS/IT 313: Software Engineering Fundamentals Requirements Analysis 1 Requirements User vs. System Requirements User requirements: description of what services that sy...

CS/IT 313: Software Engineering Fundamentals Requirements Analysis 1 Requirements User vs. System Requirements User requirements: description of what services that system is expected to provide and the constraints under which it must operate System requirements: detailed information about the system functions, services and operational constraints that are to be implemented. 2 User and system requirements 3 Requirements Functional requirements vs. Non-functional requirements Functional requirements: statements of the services that a system should provide, how the system should react to particular input and how the system should behave in particular situations. Non-functional requirements: constraints (timing, performance, reliability, development process, standards) on the services or functions offered by the system; normally apply to the system as a whole 4 Requirements Characteristics of Requirements unambiguous complete consistent (with company goals, system objectives, other requirements) traceable realistic verifiable valid 5 Requirements Engineering Activities feasibility study requirements elicitation and analysis requirements specification requirements validation 6 Requirements Elicitation and Analysis Problems/Difficulties Stakeholders don’t know what they want. Stakeholders express requirements in their own terms. Different stakeholders may have conflicting requirements. Organisational and political factors may influence the system requirements. The requirements change during the analysis process. 7 Requirements Elicitation and Analysis Activities discovery classification and organization prioritization and negotiation documentation 8 Requirements Elicitation and Analysis Classic Elicitation Techniques interviews research questionnaires observation forms analysis prototyping* 9 Prototyping Prototype a concrete model of how a system will appear or behave, and usually depict the user interface; can be classified according to fidelity: low fidelity (paper) versus high fidelity (GUI) 10 Prototyping When might prototyping be done? BEFORE the beginning: to show proof of concept to senior management IN the beginning: to gather initial user requirements AFTER the beginning: to validate evolving user requirements 11 Prototyping When might prototyping be done? during the MIDDLE stages: to validate system specifications AFTER the middle stages: to pre-train users or to create marketing demos in the LATER stages: to explore solutions to usability or design problems 12 12 Prototyping: Types Paper drawings, cutouts elicits user interface content and organization easy to annotate "Wizard of Oz" person simulates computer's behavior explores interactivity can be used as an interviewing technique 13 Prototyping: Types Mockup non-functional user interface layout using actual GUI components validates UI design aids in refining look and feel Working/Functional mockup with functional GUI components validates design explores interaction issues such as timing demonstrates progress 14 Prototyping: Techniques Throwaway prototyping creation of a simple working model of system to show users what requirements may look like when implemented requirements can be identified, simulated, and tested more quickly leads to the accurate specification of requirements, and the construction of a valid and useable system from the users’ perspective via conventional software development models 15 Prototyping: Techniques Evolutionary prototyping main goal is to build a very robust prototype in a structured manner and constantly refine it improvements and further requirements are built on the existing prototype makes use of functional prototypes 16 16 Prototyping: Advantages reduces development time and cost effective tool for building good HCI builds confidence in the customer that the developer can produce a system energizes customer/developer communication facilitates system implementation higher user satisfaction improves decisions by providing alternatives exposes developers to future enhancements 17 Prototyping: Disadvantages can focus design on aesthetics rather than functionality false impression that system will be easy to build customer may view shortcomings of prototype as flaws developers can become too attached to their prototypes time saving benefit can be lost when developing sophisticated prototypes a working prototype may be put into production! 18 Other discovery approaches Viewpoints: way of structuring requirements to represent perspectives of different stakeholders Interactor viewpoint: people or systems that interact directly with the system Indirect viewpoint: stakeholders who influence the requirements (e.g., management) Domain viewpoint: domain characteristics and constraints that influence the requirements (e.g., the law) 19 Other discovery approaches Scenarios: real-life examples of how a system can be used; includes the following: description of the starting situation description of the normal flow of events description of what can go wrong information about other concurrent activities description of the state when the scenario finishes Use cases 20 Work Products after Requirements Elicitation statement of need and feasibility bounded statement of scope list of stakeholders description of the technical environment list of requirements (preferably organized by function) prototypes developed to better define requirements 21 Requirements Specification User requirements are typically stated in natural language Problems with natural language specification ambiguity (prone to different interpretations) over-flexibility (different ways of stating the same thing) lack of modularization (inadequate to structure requirements) 22 Requirements Specification System requirements are better represented with more specialized notation Graphical models (e.g., process models, sequence diagram, data models) Tables Structured language freedom of writer is limited by a predefined template imposes a standard and a degree of uniformity limits the terminology that may be used maintains the expressiveness of natural language 23 23 Requirements Specification Form-based includes the following ▪ Definition of the function or entity ▪ Description of inputs and where they come from ▪ Description of outputs and where they go to ▪ Indication of other entities required ▪ Pre and post conditions (if appropriate) ▪ The side effects (if any) of the function 24 Requirements Specification Analysis Models: graphical representations that describe the business process and the system to be developed; serve as a bridge between analysis and design context models data-flow models state-machine models data models object models 25 Requirements Specification Software Requirements Specification (SRS): official statement of system requirements Represents WHAT the system should do, not HOW it should be done Complete specification may include the SRS, models and the prototype 26 Requirements Specification IEEE requirements standard: defines a generic structure for a requirements document Introduction General description Specific requirements Appendices Index 27 Requirements Specification Sample structure Preface Introduction Glossary User requirements definition System architecture System requirements specification System, models Appendices Index 28 Requirements Validation assessment of the quality of the requirements (checked against characteristics) determines whether the requirements actually define what the customer wants check for inconsistencies, omissions and errors techniques specification reviews prototyping test case generation 29 Requirements Management Process of identifying, understanding, tracking and controlling changes to system requirements Requirements are inevitable incomplete and inconsistent new requirements emerge priority of requirements may change (caused by: business environment change, technical environment change, better understanding of the system) system customers and end-user requirements may conflict 30 Requirements Management Requirement Management Planning involves: requirements identification change management process: focused on the impact and cost of changes traceability policies keep sufficient amount of information about requirements relationships types of traceability: source, dependency, features or design (represented using traceability matrices) CASE tool support 31 31