Software Engineering: Characteristics of Good Requirements Definition & Specification, Study Guides, Projects, Research of Software Engineering

Download Software Engineering: Characteristics of Good Requirements Definition & Specification and more Study Guides, Projects, Research Software Engineering in PDF only on Docsity! Slide 1CS 230 Introduction to Software EngineeringCopyright © K.Goseva 2006 REQUIREMENTS DEFINITION & SPECIFICATION Slide 2CS 230 Introduction to Software EngineeringCopyright © K.Goseva 2006 Requirements definition and specification • Must correctly define all of the software requirements, but no more • Should not describe any design, verification, or project management details, except for required design constraints Slide 5CS 230 Introduction to Software EngineeringCopyright © K.Goseva 2006 Characteristics of Good RD&S (Contd) • Complete • Inclusion of all significant functional and non-functional requirements • Specification of the responses to valid and invalid input values • Conformity to any standard that applies • Full labeling and referencing of all figures, tables, and diagrams and definition of all terms and units of measure • Any RD&S that uses the phrase to be determined (TBD) is not complete Slide 6CS 230 Introduction to Software EngineeringCopyright © K.Goseva 2006 Characteristics of Good RD&S (Contd) • Verifiable • There exists some finite cost-effective process which a person or machine can check that the software product meets the requirements • Examples of non-verifiable requirements statements o The product should work well o The output of the program shall usually be given within 10 s Slide 7CS 230 Introduction to Software EngineeringCopyright © K.Goseva 2006 Characteristics of Good RD&S (Contd) • Consistent • No set of individual requirements conflicts • Examples: • One requirement might state the format on the output report as tabular, but another as textual Slide 10CS 230 Introduction to Software EngineeringCopyright © K.Goseva 2006 Requirement Analysis Principles • Large number of analysis modeling methods • Common set of operational principles • The information domain of a problem must be represented and understood • The functions must be defined • The behavior as a consequence of external events must be defined • The models that depict information, function, and behavior must be partitioned in a layered (or hierarchical) fashion • Analysis process should move from essential information towards implementation detail Slide 11CS 230 Introduction to Software EngineeringCopyright © K.Goseva 2006 Information Domain • Software processes data and events (represent aspects of system control) • Information flow represents the manner in which data and control change as they move through system • Information structure represents internal organization of various data and control items Transform #1 Transform #1 Transform#2 Transform #2 Data/Control store Input object(s) Output object(s) Intermediate data and control Slide 12CS 230 Introduction to Software EngineeringCopyright © K.Goseva 2006 Modeling • Functional models • Start from context model • Over a series of iteration add more information • Behavioral models • Stimulus / response characteristics • Models • help the analyst in understanding the information, function, and behavior of the system • Are important for determination of completeness, consistency and accuracy of specification • Provide basis for design • Modeling is fundamental to good analysis work Slide 15CS 230 Introduction to Software EngineeringCopyright © K.Goseva 2006 Horizontal partitioning - functions SafeHome software Configure system Monitor sensors Interact with user Slide 16CS 230 Introduction to Software EngineeringCopyright © K.Goseva 2006 Vertical (hierarchical) partitioning - details SafeHome software Configure system Monitor sensors Interact with user Activate alarm functions Poll for sensor event Activate audible alarm Dial phone number Read sensor status Identify event type Activate / deactivate sensor Slide 17CS 230 Introduction to Software EngineeringCopyright © K.Goseva 2006 Software Requirements Specification • developed as a consequence of analysis • review is essential to ensure that the developer and the customer have the same perception of the system • even with the best of methods, the problem is that the problem keeps changing