Requirements Analysis & Requirements Specification Originally developed by Michael Madigan StorageTek Manager, PAL Engineering Software Engineering of.

Slides:



Advertisements
Similar presentations
System Integration Verification and Validation
Advertisements

Software Quality Assurance Plan
CS 411W - Notes Product Development Documentation.
Use cases.
Software Requirements Analysis and Specification C.Eng 491 Fall
COMP 350: Object Oriented Analysis and Design Lecture 3 Case Studies, Inception & Use Cases References: Craig Larman Chapters 3-6.
Requirements Specification
Fall 2009ACS-3913 Ron McFadyen1 Use Cases Used to capture functional requirements – there are other requirements categories such as usability, reliability,
8/28/2005ECEN5543 Req Elicitation1 Targets of Requirements Engineering ECEN 5543 SW Engineering of Standalone Programs University of Colorado, Boulder.
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
Use Cases & Requirements Analysis By: Mostafa Elbarbary.
Understanding Requirements
Software Engineering CSE470: Requirements Analysis 1 Requirements Analysis Defining the WHAT.
Use Cases and Scenarios
Copyright ©2004 Cezary Z Janikow 1 Use Cases n Within Requirements discipline/workflow n Verbal descriptions of important functional (behavioral, transactional,
Inception What needs to be done? Describe the vision and business case for this project. Determine if the project is feasible. Determine if the enterprise.
1 REQUIREMENTS ENGINEERING and SYSTEMS ANALYSIS Elements and Definitions.
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
The Vision Document 1. Importance of a Vision Document  It describes the application in general terms, including descriptions of the target market, the.
AGENDA Welcome and introductions Brief introduction to PSI Mobile Technical Overview Demonstration Q and A Next Actions.
RUP Requirements RUP Artifacts and Deliverables
Use Case Internals -- Compare to example in Larman text (p. 68 ff. )
Typical Software Documents with an emphasis on writing proposals.
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 06. Requirements.
Rational Unified Process (Part 1) CS3300 Fall 2015.
1 Phases in Software Development Lecture Software Development Lifecycle Let us review the main steps –Problem Definition –Feasibility Study –Analysis.
Software System Engineering: A tutorial
Requirements for Multi-Program Systems
BMAN Integrative Team Project Week 2 Professor Linda A Macaulay.
ITEC 275 Computer Networks – Switching, Routing, and WANs Week 12 Chapter 14 Robert D’Andrea Some slides provide by Priscilla Oppenheimer and used with.
Chapter 6 Use Cases. Use Cases: –Text stories Some “actor” using system to achieve a goal –Used to discover and record requirements –Serve as input to.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
IT Requirements Management Balancing Needs and Expectations.
Software Requirements Engineering: What, Why, Who, When, and How
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 20. Review Software Requirements Requirements Engineering Process.
1 Unified Modeling Language Michael K. Wildes University of California, Riverside – Extension Program Presentation 2.
Chapter 7 Applying UML and Patterns -Craig Larman
Approaching a Problem Where do we start? How do we proceed?
Lecture 7: Requirements Engineering
OOSE Use Case. Requirement Functional: –Features, capabilities, and security Non Functional: –Usability: Human factors, help, and documentation –Reliability:
1 Final Status Report Sonali PagadeNibha Dhagat David Ziman Reginald Bradshaw II Sebastian Schagerer Janet Xu Phan Marvel Electronics & Home Entertainment.
Rational Requirements Management with Use Cases v5.5 Copyright © Rational Software, all rights reserved 1 Requirements Management with Use Cases.
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 1: Introduction to Use-Case Modeling.
Faculty of Applied Engineering and Urban Planning Software Engineering Department Software Engineering Lab Use Cases Faculty of Information system Technology.
OO Methodology Inception Phase.
Business Analysis with For PG MDI, Gurgaon Kamna Malik, Ph.D.
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
CMSC 345 Fall 2000 Requirements Overview. Work with customers to elicit requirements by asking questions, demonstrating similar systems, developing prototypes,
R R R CSE870: Advanced Software Engineering: UML-- Use Cases1 Use Cases and Scenarios.
Software Engineering 1 Object-oriented Analysis and Design Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative.
Systems Development Life Cycle
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Sept Ron McFadyen1 Use Cases Introduced by Ivar Jacobson in 1986 literal translation from Swedish ”usage case” Used to capture and describe.
PRESENTATION ON USE CASE. Use Case Modeling Use case diagrams describe what a system does from the standpoint of an external observer. The emphasis is.
Understanding Requirements
Larman chapter 61 Use cases Larman chapter 6. 2 Fig. 6.1.
Requirement Elicitation Review – Class 8 Functional Requirements Nonfunctional Requirements Software Requirements document Requirements Validation and.
Requirements. Outline Definition Requirements Process Requirements Documentation Next Steps 1.
ITEC 275 Computer Networks – Switching, Routing, and WANs Week 12 Chapter 14 Robert D’Andrea Some slides provide by Priscilla Oppenheimer and used with.
1 Week 5 Software Engineering Fall Term 2015 Marymount University School of Business Administration Professor Suydam.
Jan Ron McFadyen1 Use Cases Used to capture functional requirements – there are other requirements categories such as usability, reliability,
 System Requirement Specification and System Planning.
Use Cases and Scenarios
Principles of Information Systems Eighth Edition
UML Use Case Diagrams.
Writing Use Cases.
Software Requirements Specification (SRS) Template.
Software Requirements
Use cases Dr. X.
Presentation transcript:

Requirements Analysis & Requirements Specification Originally developed by Michael Madigan StorageTek Manager, PAL Engineering Software Engineering of Standalone Programs University of Colorado, Boulder

Requirements Engineering Requirements Elicitation Requirements Analysis Requirements Specification Requirements Verification Requirements Management Requirements Engineering

Requirements Analysis & Specification Definitions Requirements Analysis – The process of studying and analyzing the customer and the user/stakeholder needs to arrive at a definition of software requirements. 1 Requirements Specification – A document that clearly and precisely* describes, each of the essential requirements of the software and the external interfaces.  (functions, performance, design constraint, and quality attributes) – Each requirement is defined in such a way that its achievement is capable of being objectively verified by a prescribed method; for example inspection, demonstration, analysis, or test. 2

Types of Requirements Functional requirements Performance requirements – Speed, accuracy, frequency, throughput External interface requirements Design constraints – Requirements are usually about “what”, this is a “how”. Quality attributes – i.e. reliability, portability, maintainability, supportability

What vs. How Dilemma 3 User Needs System Requirements System Design Software Requirements Software Design What How

Requirements vs. Design RequirementsDesign Describe what will be delivered 3 Describe how it will be done 3 Primary goal of analysis: UNDERSTANDING 3 Primary goal of design: OPTIMIZATION 3 There is more than one solutionThere is only one (final) solution Customer interestedCustomer not interested (Most of the time) except for external

Software Quality Attributes 4 Correctness Reliability – Rating = 1 – (Num Errors/ Num LOC) – Can be allocated to subsystems Efficiency Integrity Usability Survivability Maintainability Verifiability Flexibility Portability Reusability Interoperability Expandability

Analysis of Elicitation results helps to create a Vision Settle on which problem - Explain in the problem statement (2.2) Marketing group establishes positioning of the product (2.3) Stakeholder and User Summaries - User is a special case of stakeholder - Identify all stakeholders w.r.t. development: NameRepresentsRole - Identify all users w.r.t. system: Name DescriptionStakeholder

Stakeholder Profiles (3.5) Representative - who (name) is representing this stakeholder type. Description - brief description of the stakeholder type Type - Qualify s-h’s expertise, technical background, degree of sophistication Responsibilities - List s-h’s key responsibilities with regard to the system being developed - why a stakeholder? Success Criteria - How does the stakeholder define success? How rewarded? Involvement - involved in the project in what way? Requirements reviewer, system tester,... Deliverables* - required by the stakeholder Comments/Issues - Problems that interfere w/ success, etc.

User Profiles (3.6) Representative - Who represents this user? (might be a stakeholder) Description - of the user type Type - qualify expertise, technical background, degree of sophistication Responsibilities - user’s key resp.’s w.r.t. system being developed Success Criteria - how this user defines success? rewarded? Involvement - How user involved in this project ? what role? Deliverables - Are there any deliverables the user produces ? For whom? Comments/Issues - Problems that interfere w/ success, etc. This includes trends that make the user’s job easier or harder

User Environment (3.4) -- working environment of target user Number of people involved in doing this now? Changing? How long is a task cycle now? Changing? Any unique environmental constraints: mobile, outdoors, in- flight, etc. Which system platforms are in use today? future? What other applications are in use? Need to integrate?

Key Stakeholder or User Needs (3.7) List key problems with existing solutions as perceived by the stakeholder or user. What are the reasons for this problem? How is it solved now? What solutions does the stakeholder want? What is relative importance of solving each problem? Alternatives and Competition (3.8)

Product Overview (4.) (at last!) 4.1 Product perspective (context) Put the product in perspective to other related products and the user’s environment. Independent? Component of a larger system? How do the subsystems interact with this? Known interfaces between them and this component? Block diagram

Product Overview (4.) (at last!) 4.2 Summary of Capabilities Customer Benefit Supporting Features

Product Overview (4.) (at last!) 4.3 Assumptions and dependencies What factors affect the features above? List assumptions that, if changed, ALTER this document 4.4 Cost and pricing -- not done by engineering 4.5 Licensing and installation -- different types of license enforcement will create more requirements for the development effort

What’s a feature? - high level capability necessary to deliver benefit to the user - externally desired service that typically requires inputs to achieve Level of detail must be general -- this is not the requirements spec for the developers. Provide the basis for product definition, scope management, and project management. Each will be expanded in the use-cases or other requirements Externally perceivable by users or external systems Product Features (5.)

What is not in the Product Features Section? Design Constraints -- These go in section 6. – Design constraints – External constraints Quality Ranges -- These go in section 7 – ranges for performance, robustness, fault tolerance, etc. that are not really features (specific capabilities, functions)

Precedence and Priority (8.) Which features essential ? – We will delay shipment in order to have these – We will postpone the feature in order to meet first-release goal

Other Product Requirements These are requirements that are not features (functions) of the product – hardware platform requirements -- – system requirements -- supported host o.s.’s, peripherals, companion software – environmental requirements -- temperature, shock, humidity, radiation, usage conditions, resource availability, maintenance issues, type of error recovery – applicable standards -- legal, regulatory, communications

Documentation Requirements What must be developed to support successful deployment? – User Manual? – Online Help? – Installation guide? Read Me file? – Labeling, packaging?

Vision Doc adds basis for SRS

Use Case Internals -- Compare to example in Larman text (p. 68 ff.). Terms: Use Case Name Scope Level Primary Actor Stakeholders & interests Preconditions Success Guarantee (post- conditions) Basic Flow Alternate Flows (extensions) Error Flows Subflows Special requirements Technology & data variations list Frequency of occurrence Open Issues

Fully Dressed Example: Process Sale, Larman text, p. 68 ff. Primary Actor: Cashier Stakeholders and Interests: - Cashier: Wants accurate, fast entry, and no payment errors, as cash drawer shortages are deducted from his/her salary. - Salesperson: Wants sales commissions updated. - Customer: Wants purchase and fast service with minimal effort. Wants proof of purchase to support returns. - Company: Wants to accurately record transactions and satisfy customer interests. Wants to ensure that Payment Authorization Service payment receivables are recorded. Wants some fault tolerance to allow sales capture even if server components are unavailable. Wants automatic and fast update of accounting and inventory.

Fully Dressed Example: Process Sale, Larman text, p. 68 ff. - continued - Government Tax Agencies: Want to collect tax from every sale. May be multiple agnecies such as national, state, and county. - Payment Authorization Service: Wants to receive digital authorization requests in the correct format and protocol. Wants to accurately account for their payables to the store. Preconditions: Cashier is identified and authenticated. Success Guarantee (Postconditions): Sale is saved. Tax is correctly calculated. Accounting and Inventory are updated. Commissions recorded. Receipt generated. Payment authorization approvals are recorded.

Fully Dressed Example: Process Sale, Larman text, p. 68 ff. - continued Main Success Scenario (of Basic Flow): Extensions (Alternative Flows): *a. *b. 1a 2-4a 3a. 3b. 3c. 3-6a-c 4a 5a-c 6a 7a-f 9a-c

Special Requirements: - Touch Screen UI on a large flat panel monitor. Text visible from 1 meter. - Credit auth. response within 30 seconds 90% of the time.... Technology and Data Variations List:... Frequency of Occurrence: Could be nearly continuous. Open Issues: - What are the tax law variations? - Explore the remote service recovery issue. - What customization is needed for different businesses? Fully Dressed Example: Process Sale, Larman text, p. 68 ff. – cont.

Now what -- after development of use case(s) Look for consistency, correctness, completeness – Most important for core requirements likely to be implemented soon By translation to other formats – See Vision Document – State diagrams and tables – Event tables – Condition tables – Domain diagram (UML)

References 1 “Requirements Analysis,” Richard Thayer, SMC 10/97 Version 2, “IEEE Guide for Software Requirements Specification,” IEEE “Software Requirements:Objects, Functions, and States”, Prentice Hall, Software Quality Measurement for Distributed Systems, RADC-TR