1 / 53

Requirement Document

Requirement Document. CS130 Software Engineering Winter02. 0. Table of Contents 1. Introduction     1.1 General Information     1.2 Overview     1.3 Customers     1.4 Goals of the Project     1.5 Major Constraints     1.6 Method     1.7 Process 2. System Functions and System Attributes

barrett-hall
Download Presentation

Requirement Document

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. Requirement Document CS130 Software EngineeringWinter02

  2. 0. Table of Contents 1. Introduction     1.1 General Information     1.2 Overview     1.3 Customers     1.4 Goals of the Project     1.5 Major Constraints     1.6 Method     1.7 Process 2. System Functions and System Attributes     2.1 System Functions     2.2 System Attributes 3. Use Cases 4. Data Flow Diagrams     4.1 Level 0 DFD        4.2 Level 1 DFD 5. Preliminary Users Guide     5.1 Screen Shots     5.2 Screen Navigation Diagram 6. Project Planning     6.1 Work Breakdown Schedule     6.2 Work Input Summary 7. Appendix     7.1 Data Dictionary     7.2 Correspondence With Sapient Requirements Document Outline

  3. 1. Introduction 1.1 General Information     1.2 Overview     1.3 Customers     1.4 Goals of the Project     1.5 Major Constraints     1.6 Method     1.7 Process 1.1 General Information Who is in your team? What is your team name? Team name must start with your group letter If your team has an unusual name, please tell us how you chose it. Who is your Sapient contact? Who is the group contact? Requirement Document Introduction

  4. 1. Introduction 1.1 General Information     1.2 Overview     1.3 Customers     1.4 Goals of the Project     1.5 Major Constraints     1.6 Method     1.7 Process 1.2 Overview 3-4 sentences What are your customer’s needs? How does/will your project address these needs? Provide a short description of the system you'll be building. Requirement Document Introduction

  5. 1. Introduction 1.1 General Information     1.2 Overview     1.3 Customers     1.4 Goals of the Project     1.5 Major Constraints     1.6 Method     1.7 Process 1.3 Customers Give some corporate information Who are the customers? 1.4 Goals of the Project Goals specific to the customers’ requirements What are you trying to provide? Include the business and technical goals of this project, as well as the goals of your team (for example, learning ASP, gaining software engineering experience). Requirement Document Introduction

  6. 1. Introduction 1.1 General Information     1.2 Overview     1.3 Customers     1.4 Goals of the Project     1.5 Major Constraints     1.6 Method     1.7 Process 1.5 Major Constraints Resources, experience, time 1.6 Method Structured analysis, Object oriented analysis, etc Why? 1.7 Process Linear-sequential, prototyping, RAD, Incremental, spiral, etc Which development process did you select, and why? Requirement Document Introduction

  7. Requirement Document- System Functions and System Attributes 2.1 System Functions • Functionalities that your software provides • Rule of thumb: each function should start with a verb • Examples: • Prompt user for login name • Verify if user is valid • Display list of transactions • Should be listed and grouped logically • Each function is categorized as either: • Evident (public): user is aware of the function • Hidden (private): user is not aware • Each function is assigned a reference number • Each function does not necessarily correspond to a programming function/procedure

  8. System Functions -Examples Authenticate Functions

  9. System Functions-Examples Add User Functions

  10. System Functions- Examples Edit User Password Functions

  11. Requirement Document- System Attributes • Characteristics or dimensions of your system • Not functions • Measurable or tangible • Examples: • System response time • Client hardware • Client software • Server software • Ease of use • Database engine • Web Browser versions • Each attribute needs details and/or boundary constraints • explain your choice for each attribute • be as specific and/or quantitative as possible • if listing a quantitative metric, explain where you got that number

  12. Requirement Document- Use Cases • Narrative descriptions of a user’s actions and how your system responds • Must have a Use Case for every available user action, such as pressing a button or choosing from a menu • Each case represents a large, multi-step process • Preconditions: what needs to occur before the use case can proceed • A numbered table of steps of Actor’s actions and system’s responses • Alternative courses: exceptions or error-handling events that occur for a specific step

  13. Requirement Document- Use Cases • For each Use Case, you need to list: • A descriptive name • Actors (users): person who initiates action • Purpose: intention of the case • Overview: 3-4 sentence summary • Type: {primary, secondary} and {essential, real} • primary: major process • secondary: minor or rare process • essential: abstract with no implementation details • real: has concrete details on implementation with • specific inputs and outputs • Cross-references: related use cases, system functions, and/or screen shots; reference is to a unique identifier

  14. Alternative Courses:

  15. Alternative Courses:

  16. Alternative Courses:

  17. Alternative Courses:

  18. Requirement Document- Data flow Diagrams • no PSPEC (process specification) or CSPEC (control specification) in Level-1 DFD • Don’t need to represent every System Function • Include topmost 6-7 functions • User authentication • Searching • Add Materials • Updating Materials, etc.

  19. Requirement Document- Data flow Diagrams • Common DFD Errors: • Process1 has inputs but produces no outputs. This is called a black hole • Process 2 produces outputs but receives no inputs. This is called a miracle • Process 3 has inputs and outputs ; however the inputs are not sufficient to produce the outputs. This is called a gray hole.

  20. The Explosion Approach to drawing DFDs:As suggested by DeMarco and others, this diagramming technique requires the analyst to draw multiple DFDs, each one exploding from a single process on another diagram, until the system is completely modeled A m Z The System p B n A C Z 1. 2. Overview DFD ZZZ E D B 3. A K D 1.1. B G 3.1 3.2 1.2 L H 1.3 XXX C M

  21. id 2.0 3.0 1.0 1.1 1.2 2.1 2.2 1.3 2.3 1.4 1.4.1 1.4.2 1.4.3 1.4.4 Functional Decomposition and Leveled DFDs Parent Explodes to Explodes to Child Child Level 1 Diagram 1 Level 1 Diagram 2 Explodes to Level 2 Diagram 1.4 Grandchild

  22. Requirement Document- Preliminary User’s Guide • 5. Preliminary User’s Guide • 5.1 Screen Shots • Have a screen shot for each (planned) screen • 1-2 shots per page, with: • Unique identifying number (e.g. 5.1.1, 5.1.2) • Short unique title • 2-3 sentence description • Actual screen shot • Be sure to show error screens

  23. Requirement Document- Preliminary User’s Guide • 5.1 Screen Shots • Each screen shot should be labelled with a unique identifier (e.g., "Figure 1"), • should have a title, and there • short narrative description of the functionality associated with the screen.  • Each screen shot should also refer back to the appropriate system functions in Section 2.  • PLEASE make sure that the screen shots are readable when printed out

  24. Requirement Document- Preliminary User’s Guide • 5.2 Screen Navigation Diagram • Diagram represents each screen (from 5.1) as a rectangle with arrows showing path to another screen • Each rectangle must have same unique title as in 5.1 • Each arrow must be labeled with an action • Each screen from 5.1 must be represented in diagram

  25. Requirement Document- Preliminary User’s Guide • 5.2 Screen Navigation Diagram • Here's where you show how to get from one screen to the others • There should be a 1-1 correspondence between the screen shots in section 5.1 and the nodes in the screen navigation diagram.  • Each node should be identified with the unique identifier (preferable) or title of the corresponding screen shot.  • Make sure that all of the links between nodes are labelled, and that the direction of the link is indicated.

  26. Requirement Document- Project Planning • The Project Plan consists of 2 parts, the WBS or Work Breakdown Structure and the Work Input Summary. • Here is an outline with examples:

  27. Requirement Document- Work Breakdown Structure

  28. Note: This table should be as complete as possible. For each task, the Planned Start, Planned Complete, Assigned Person and Time allocated columns must be filled in! The remaining columns shoud be filled in as the tasks are started and completed. Milestones do not need an assigned person, time allocated or actual time.

  29. Requirement Document- Work Input Summary • 6.2 Work Input Summary • Please include a paragraph or more discussing the following questions: • 1. How many hours are allocated for each team member? • 2. How many hours are allocated for the entire project? • 3. Is this a reasonable estimate? Why? Why Not? • 4.  Of the tasks that have been completed, how many hours have been allocated for the project? • 5.  How may hours were needed to complete these tasks? • 6. What is your estimation ratio? (Actual Time / Time Allocated) • 7. What does this tell you about your project?

  30. Requirement Document- Work Input Summary(1) Some Sample Calculations: 1. Total hours allocated for each team member   Jennifer: 1 + 1 + 2 + 20 + 5 + 3  =  32 hours   Alice:      1 + 10 + 2 +  5  + 3       =  21 hours   Bob:         1 + 10 + 2 +  5 +  1       = 19 hours 2.   Estimated hours for the entire project: (note: 3 team members, so the hours assigned to each task for "All" is  multiplied by 3) = 1 hours * 3 persons + 1 hour * 1 person + 10 hours * 1 person  + 10 hours * 1 person  + 2 hours * 3 persons + 20 hours * 1 person + 5 hours  * 3 persons + 3 hours  * 2 persons + 1 hour * 1 person = 3 + 1 +10 +10  + 6 + 20 + 15 + 6  + 1 Estimated person hours for the  project = 72. (note: this number should also be the sum of the allocations for each member ) Check: 32 + 21 + 19 = 72

  31. Requirement Document- Work Input Summary 4.  Use the same method as in #2, except only add the tasks that have been completed. In my example, I have completed all of my tasks, so the allocated hours will be 72. 5.  Actual Time: =    1 * 3 + .5  + 6 + 15  + 2 * 3  + 15  + 6 * 3 + 2 * 2 + 3 =     3  + .5 + 6 + 15 + 6 + 15 + 18 + 4 + 3 =    70.5 6. Estimation Ratio  Actual Time / Time Allocated = 70.5 / 72 = .979 You do not need to show these calculations, just show the summary numbers. However, if you use a different method to do the calculations, then  explain how you derived your answers.

  32. Requirement Document- Appendix • 7. Appendix • 7.1 Data Dictionary • List and define all interesting terms from the project • Expand acronyms • Bad example: • TAR: Technical Assistance Request • Good example: • TAR: Technical Assistance Request. A document used by Sapient to describe troubles or issues regardinga consultation project. • Bad example: • User: some dude/dudette • Good example: • User: the basic lowest priveleged user in the Webtracker system. Clients and developers are usually Users. Users have the capabilities of viewing, adding,modifying, and searching TARs. • List all technical terminology, e.g. ASP, IIS

  33. Requirement Document- Appendix • 7.2 Correspondence with Sapient • All e-mails between yourself and your Sapient contact • Include From, To, Subject, and Date • Include your question and their reply • Make sure to include ALL of your correspondence with Sapient.  PLEASE keep the headers with the messages.  • It may happen that you don't get answers to your messages - that's OK, but make sure that all of the messages you've sent out are included.  If you don't hear back from your contact, make sure to include in this section any assumptions you've had to make because there's been no reply to your messages.

  34. TIP: In addition to discussing additions or changes to functionality and behavior, your contact at Sapient will probably be interested in looking at the system functionality, the screen shots, and the screen navigation diagram.  As you complete each of those sections, you might want to send it out to them to get their comments.  Make sure to allow your contact a couple of days to respond to what you've sent.

  35. Extra Notes on Development Models

  36. Lifecycle Models • Build-and-fix • develop system • without specs or design • modify until customer is satisfied • Why doesn’t build-and-fix scale? • changes during maintenance • most expensive!

  37. Requirements Phase Requirements Description Specification Phase Specification Design Phase Design Docs Implementation & Integration Phase Product Lifecycle Models • Staged models • successive stages of development • e.g., waterfall model

  38. Lifecycle Models • Rapid prototyping • build something users can understand & assess • often focuses on the interface • e.g., Wizard of Oz studies • waterfall model follows the prototype • Incremental (aka Evolutionary) development • incrementally expand the system • can be used to do a “phased delivery” to users • more expectation management needed! • build-and-fix revisited?

  39. Lifecycle Models • Spiral Model • risk-driven approach • assess risks before each phase • what is the difficulty here? • re-assess in frequent cycles • OO Models • more interaction between phases • more iteration within phases

  40. Requirements Phase Requirements Description Specification Phase Specification, SPMP Design Phase Design Docs Implementation & Integration Phase Product Operations Mode Retirement Waterfall Model Verify output of stages Flaw? original model didn’t let you go back!

  41. Advantages of Waterfall Model • Enforced discipline through documents • no phase is complete until the docs are done & checked by SQA group • concrete evidence of progress • makes which costly phase easier? • Testing is inherent in every phase • continuously as well as at end of phases

  42. Drawbacks of Waterfall Model • Document-driven model • customers cannot understand these • imagine an architect just showing you a textual spec! • first time client sees a working product is after it has been coded. Problem here? • leads to products that don’t meet customers needs • Assumes feasibility before implementation • re-design is problematic • works best when you know what you’re doing • when requirements are stable & problem is well-known

  43. Rapid Prototyping • Rapid prototyping as a requirements tool • allow users to “see” & use proposed solutions • develop specification from the prototype/requirements • proceed with rest of stages in waterfall model • Prototype must be constructed & changed quickly • do not spend a lot of time perfecting the code/structure • plan to throw it away! because you will! • put in front of customer ASAP • user interface prototyping & other rapid dev tools make this easier

  44. Assessment of RP Model • Advantages ? • process proceeds linearly (less need for feedback loops) • easier to take technology risks with the prototype • Disadvantages • expectation management • delivering “everything” properly takes time • turning prototypes into production code • quite controversial... • will turn into build-and-fix

  45. Requirements phase Verify Specification Maintenance Development phase Verify Architectural design Verify For each build: Perform detailed design, imple- mentation, and integration. Test. Deliver to client. Operations mode Retirement Incremental Model • Divide project into builds • each adds new functions • each build integrated w/ structure & product tested as a whole • Advantages ? • operation product in weeks • less traumatic to organization • smaller capital outlay, rapid ROI • Disadvantages ? • need an open architecture • a big advantage come maintenance! • too few builds  build-and-fix • too many builds  overhead

  46. Other Incremental Models • Advantages ? • more parallelism saves lots of time! • Risks ? • no overall design at start pieces might not fit together

  47. Synchronize & Stabilize Model (Microsoft) • Requirements analysis • interview potential customers • Draw up overall product specifications • Divide project into 3 or 4 builds • each adds new functionality (1st gives base) • each build carried out by small parallel teams • At the end of day – synchronize (test & debug) • At end of build – stabilize (fix & freeze build)

  48. Spiral Model • Always some risk involved in software development • people leave… other products not delivered on time… • Key idea • minimize risk • e.g., building prototypes & simulations minimizes risks • Precede each phase by • looking at alternatives • risk analysis • Follow each phase by • evaluation • planning of next phase

  49. Spiral Model

More Related