Requirements analysis Requirements Analysis and Specification 1 Requirements

  • Slides: 14
Download presentation
Requirements analysis Requirements Analysis and Specification 1

Requirements analysis Requirements Analysis and Specification 1

Requirements / specification Requirements Analysis and Specification requirements customer developer specifications 2

Requirements / specification Requirements Analysis and Specification requirements customer developer specifications 2

Requirements analysis and specification Requirements Analysis and Specification: Requirements / Specification: ----What is needed?

Requirements analysis and specification Requirements Analysis and Specification: Requirements / Specification: ----What is needed? ----If there is a current implementation, what are the problems with it? ----How can we translate customer needs and wants into a usable specification for the design stage? Initially, requirements may be fuzzy and poorly stated--analysis stage sharpens and focuses the (customer) requirements 3

Example: let’s redesign windows ----What is needed? ----Current implementation: what are the problems with

Example: let’s redesign windows ----What is needed? ----Current implementation: what are the problems with it? ----How can we translate customer needs and wants into a usable specification for the design stage? Initially, requirements may be fuzzy and poorly stated--analysis stage sharpens and focuses the (customer) requirements 4

Example requirements analysis process An example requirements analysis process: FAST (Facilitated Application Specification Techniques,

Example requirements analysis process An example requirements analysis process: FAST (Facilitated Application Specification Techniques, in R. A. Zahniser, Building Software in Groups, American Programmer 3 (7 -8), July-August, 1990. ): GOAL: identify problem, negotiate differences, specify preliminary set of solution requirements --engineers AND customers meet at a neutral site --there are rules for preparation and participation in this meeting --agenda covers all important points but also allows flexibility for free flow of ideas --meeting controlled by facilitator --definition mechanism chosen (e. g. , flip charts, electronic bulletin board. , etc. ) 5

Tools for requirements analysis Some tools for requirements analysis & specification: Requirements: ----formal requirements

Tools for requirements analysis Some tools for requirements analysis & specification: Requirements: ----formal requirements document Specification: ----use cases (UML) ----”user stories” (XP) 6

Requirements document must be as clear as possible, consistent, complete Important parts of a

Requirements document must be as clear as possible, consistent, complete Important parts of a requirements document (Berezin, 1999): 1. Application Overview: -- objectives -- (business process—how application fits) -- user roles and responsibilities -- interactions with other systems -- (replacement of legacy systems) -- (production rollout considerations) 7 -- terminology

Requirements document--continued Important parts of a requirements document (continued): 2. Functional requirements: -- functionality

Requirements document--continued Important parts of a requirements document (continued): 2. Functional requirements: -- functionality precise, detailed, for each user class address security, auditing, reporting, ability of users to modify application -- (scope (for a multiphase project) ) 3. Quality requirements --performance (space / time / power) -- usability -- concurrency --portability --security / reliability --etc. 8

Specification: must be as complete as possible, consistent, clear 9

Specification: must be as complete as possible, consistent, clear 9

Principles of specification: 1. functionality should be separate from implementation 2. model of system

Principles of specification: 1. functionality should be separate from implementation 2. model of system behavior must include both data and functional responses to external stimuli 3. interaction with other components must be specified 4. environment of operation must be defined 5. "cognitive model" should describe the system as seen by the user community; do not create a design or implementation model 6. must be tolerant of incompleteness and allow for additions 7. must allow for change 10

Software requirements specification Result of specification step: Software Requirements Specification must include: --complete information

Software requirements specification Result of specification step: Software Requirements Specification must include: --complete information description --detailed functional description --representation of system behavior --performance requirements --design constraints --appropriate validation criteria (for example, acceptance tests) --……. 11

Specification format example candidate formats for specification: IEEE 830 -1984 Department of Defense at

Specification format example candidate formats for specification: IEEE 830 -1984 Department of Defense at the end of this process, customer and developer must conduct a Specification Review 12

Specification—one example “Redesign windows” requirement specification for new product? 13

Specification—one example “Redesign windows” requirement specification for new product? 13

Quarter Project This quarter: • Requirements will be written following the outline in the

Quarter Project This quarter: • Requirements will be written following the outline in the paper by Berezin • Specifications will be written as UML use cases, along with text descriptions • System acceptance tests will be written along with specifications 14