lecture_02

lecture_02 - Coming up: What is a requirement? 1 Software...

Info iconThis preview shows pages 1–10. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Coming up: What is a requirement? 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 5 Requirements Engineering Modified to include some Agile Concepts copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. NOTE: Some slides referenced from: Ian Sommerville Slides for Software Engineering. Last time n Overview of software engineering n What is software engineering? Why do we need it? n What are some of the key principles? n Introduction to process models n Basic process model: waterfall model n Start with gathering requirements AAA 2 This week n Specification n Requirements n UML AAA 3 What is the most difficult part of developing software? AAA 4 Coming up: Requirements come in many forms 5 What is a requirement? n Requirements are used to describe all aspects of a system n They may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification n They serve many roles n May be the basis for a bid for a contract - therefore must be open to interpretation n May be the basis for the contract itself - therefore must be defined in detail n Are always used to communicate what you intend to build Requirements come in many forms n Requirements Statements n ex: “The system shall ….” n UML Use-case diagrams n eXtreme Programming “User Stories” n Any other documents that communicate what you intend to build n Prototypes can be used as requirements n Existing systems can serve as requirements “Build this system, but use Java instead of Fortran” n UML Sequence diagrams, State charts, activity diagrams… 6 Coming up: All Requirements Coming up: Typical Requirements Statements 7 All Requirements n Should specify external behavior of the system n what the system does, not how n Includes functional and non-functional requirements n Functional requirements are statements of the services that the system must provide n What must the system do? (Start all with the phrase “The system shall…”) n Non-functional requirements are constraints on the services and functions offered by the system n How must it do it? or a constraint on the system Coming up: Why do we care? 8 Typical Requirements Statements n Functional : The system shall display the heart rate, blood pressure and temperature of a patient connected to the patient monitor. n Non-Functional: "Display of the patient's vital signs must respond to a change in the patient's status within 2 seconds.” n ‘ilities’ - Performance, Scalability, Capacity, Availability Reliability, Recoverability, Maintainability, Serviceability, Security,Regulatory, Manageability What are some functional requirements on an iPod? Non-functional? Coming up: Why do we care?Coming up: Why do we care?...
View Full Document

This note was uploaded on 03/26/2012 for the course CS 321 taught by Professor Kinga during the Spring '12 term at George Mason.

Page1 / 41

lecture_02 - Coming up: What is a requirement? 1 Software...

This preview shows document pages 1 - 10. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online