1 / 19

22 January

22 January. Requirements (cont.) Software Engineering Overview. Team Rules. Handled the simple questions What are your back up plans? How are you going to recognize if someone is behind? Extended absences. Requirement Level. Often addressed in two phases Customer level

amity
Download Presentation

22 January

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. 22 January Requirements (cont.) Software Engineering Overview

  2. Team Rules • Handled the simple questions • What are your back up plans? • How are you going to recognize if someone is behind? • Extended absences

  3. Requirement Level • Often addressed in two phases • Customer level • Developer level (will visit later) • Once agreement exists with customer, developer “translates” them into his language • Example • User must never lose more than 10 minutes of work • Autosaving is required

  4. Sources of requirements • People • Broad range of stakeholders • Conflicting requirements • Wants and needs • Helping the customer articulate the requirements: use cases • Hardware constraints • Laws of physics and nature • Social responsibility

  5. decision support system for military tactics video game unconstrained corporate accounting system Type of application manufacturing control system enhancement to corporate accounting system flight control system for airliner highly constrained missile guidance system % of requirements gathered from people Relatively low Relatively high Sources of Requirements: People vs. Other (Brackett, CMU)

  6. What is a Functional Spec? • Describes the features of the software product • Describes the product's behavior as seen by an external observer • Contains the technical information and data needed for the design • Defines what the functionality will be, but not how it will be implemented

  7. Why a Spec? • Allows you to communicate with your client and users • Easier to change than code • Basis for schedule • Record of design decisions

  8. What’s in a Functional Spec? • Overview • Use cases (scenarios) • Interfaces: anything the USER sees • As much as you know • Note: your functional spec witll go through multiple iterations

  9. Reference (thanks to Shaddi) • Joelonsoftware.com

  10. Software Engineering

  11. Expectations of Software Engineering(Watts Humphrey) • Predetermine quantitative quality goals • Accumulate data for use in later projects • Keep all work visible • Design, program and test only against requirements • Measure and achieve quality goals

  12. Keeping Work Visible: Documentation • What will be implemented • Customer: contract, requirements, “glossy” • User: manuals • How it will be implemented • Project plan • The code • The test plan • What people will do • How you will manage code and documents

  13. Documentation Principles • Need to reflect changes • Version control • Need to keep all documents synchronized • Single owner • Only say it once

  14. Quality Management Principles • Customer focus • Leadership • Involvement of people • Process approach • System approach to management • Continual improvement • Factual approach to decision making • Mutually beneficial supplier relationships http://www.iso.ch/iso/en/iso9000-14000/iso9000/qmp.html

  15. Customer Focus • Organizations depend on customers • Understand needs, requirements, expectations • Increases market share • Implies • Market research • Customer understanding throughout the organization • Measuring satisfaction

  16. Involvement of People • Essence of the organization • “Buy in” • Two way street • Treating people with respect • They will take on ownership of responsibility • Encourage a collaborative environment

  17. Software Engineering Fundamental Steps • Requirements • Design • Implementation • Integration • Test (elaborated versions to be covered later)

  18. Processes • Differ by how often you do the steps • Points on the spectrum • Differences in overhead • Three fundamental models • Waterfall • Spiral • Iterative

  19. Waterfall • Do it once • Traditional model • Used for large next version releases, especially when tightly coupled changes • Pros • Simple documentation management • Clean design phase • Cons • Least flexibility • No early feedback

More Related