Requirements Specification. Welcome to Software Engineering: “Requirements Specification” “Requirements Specification”  Verb?  Noun?  “Specification”

Slides:



Advertisements
Similar presentations
Software Requirements
Advertisements

Properties of Good Requirements Chapter 8. Understandable by end users  End-users are not often software engineers.  Terminology used must agree with.
Describing Process Specifications and Structured Decisions Systems Analysis and Design, 7e Kendall & Kendall 9 © 2008 Pearson Prentice Hall.
Requirement Analysis and Specification Mr. Manoj Kumar Kar.
Introduction to Software Engineering Dr. Basem Alkazemi
Introduction to Software Engineering
Chapter 9 Describing Process Specifications and Structured Decisions
1 / 26 CS 425/625 Software Engineering Software Requirements Based on Chapter 5 of the textbook [Somm00] Ian Sommerville, Software Engineering, 6 th Ed.,
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
7M701 1 Software Engineering Software Requirements Sommerville, Ian (2001) Software Engineering, 6 th edition: Chapter 5
CS 425/625 Software Engineering Software Requirements
Software Requirements
Soft. Eng. II, Spr. 2002Dr Driss Kettani, from I. Sommerville1 CSC-3325: Chapter 1 (cont ’d) Title : Client requirements (Review) Mandatory reading: I.
Business Area Analysis Focus: Domain View (selected business area) Goals: –Isolate functions and procedures that allow the area to meet its goals –Define.
SE 555 Software Requirements & Specification Requirements Validation.
Overview of Software Requirements
Ch5: Software Specification. 1 Overview  Use of specifications  Specification qualities  Classification of specification styles  Verification of specifications.
SE 555 – Software Requirements & Specifications Introduction
1 Software Requirements Specification Lecture 14.
1 REQUIREMENTS ENGINEERING and SYSTEMS ANALYSIS Elements and Definitions.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Requirements engineering l The process of establishing the services that the.
S R S S ystem R equirements S pecification Specifying the Specifications.
Software Engineering 2003 Jyrki Nummenmaa 1 REQUIREMENT SPECIFICATION Today: Requirements Specification Requirements tell us what the system should.
Applying the Inspection Process. What Software Artifacts Are Candidates for Inspection? Software Requirements Software Designs Code Test Plans.
SE-02 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. Requirements.
Topics Covered: Software requirement specification(SRS) Software requirement specification(SRS) Authors of SRS Authors of SRS Need of SRS Need of SRS.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
Requirements Engineering How do we keep straight what we are supposed to be building?
Instructor: Peter Clarke
Mathematical Modeling and Formal Specification Languages CIS 376 Bruce R. Maxim UM-Dearborn.
Dr. Tom WayCSC Software Requirements CSC 4700 Software Engineering Lecture 2 Based on Sommerville, Chapter 6.
Introduction to Formal Methods Based on Jeannette M. Wing. A Specifier's Introduction to Formal Methods. IEEE Computer, 23(9):8-24, September,
Ch. 51 Specification. Ch. 52 Outline Discussion of the term "specification" Types of specifications –operational Data Flow Diagrams (Some) UML diagrams.
1 Specification Some slides for Chapter 5 Of Ghezzi, Jazayeri, and Mandrioli.
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
CT1404 Lecture 2 Requirement Engineering 1 1. Today's Lecture Definition of a Software Requirement Definition of Software Requirements Management Characteristics.
L To identify the services that the customer requires from a system and the constraints under which it operates and is developed.
1 Quality Attributes of Requirements Documents Lecture # 25.
Formal Methods.
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
Week 3: Requirement Analysis & specification
Software Requirements Specification (SRS)
System Requirements Specification
Prof. Hany H. Ammar, CSEE, WVU, and
Software Requirements Specification Document (SRS)
Requirements Analysis
Capturing Requirements. Questions to Ask about Requirements 1)Are the requirements correct? 2)Consistent? 3)Unambiguous? 4)Complete? 5)Feasible? 6)Relevant?
1 Specification A broad term that means definition Used at different stages of software development for different purposes Generally, a statement of agreement.
CSC480 Software Engineering Lecture 7 September 16, 2002.
Software Engineering, COMP201 Slide 1 Software Requirements BY M D ACHARYA Dept of Computer Science.
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.
2009 copyright Leslie Munday University Requirements Management and Traceability For IIBA By Leslie Munday.
Requirement Specification SRS document is a contract between the development team and the customer How do we communicate the Requirements to others? Firm.
Dillon: CSE470: ANALYSIS1 Requirements l Specify functionality »model objects and resources »model behavior l Specify data interfaces »type, quantity,
1 Software Requirements Descriptions and specifications of a system.
 System Requirement Specification and System Planning.
An Overview of Requirements Engineering Tools and Methodologies*
Chapter 4 – Requirements Engineering
Chapter 4 – Requirements Engineering
Chapter 5 – Requirements Engineering
Verification and Validation Overview
Requirement Engineering
System Requirements Specification
Software Verification and Validation
Software Verification and Validation
Chapter 11 Describing Process Specifications and Structured Decisions
Lecture # 7 System Requirements
Software Verification and Validation
Subject Name: SOFTWARE ENGINEERING Subject Code:10IS51
Presentation transcript:

Requirements Specification

Welcome to Software Engineering: “Requirements Specification” “Requirements Specification”  Verb?  Noun?  “Specification” not the same as “Requirements Specification”?  “Requirements” not the same as “Specification”?

Requirements vs Specifications A specification is a precise statement of the requirements that the system must satisfy. A specification is a precise statement of the requirements that the system must satisfy.

Requirements Specification Sommerville: is the activity of translating the information gathered during the analysis activity into a document that defines a set of requirements. IEEE: Requirements specification is documentation of the essential requirements (functions, performance, design constraints, and attributes) of the software and its external interfaces. (STD 1012)

Uses of requirements Statement of the needs of the users Statement of the needs of the users Statement of the things the system has to do for the designers. Statement of the things the system has to do for the designers. Statement of reference for maintenance Statement of reference for maintenance

Formality Informal: not formal Informal: not formal Formal (Davis): Written down in an SRS in a natural language (e. g. English). Formal (Davis): Written down in an SRS in a natural language (e. g. English). Formal (Ghezzi): Written down in a formal specification language (e. g. Z, Larch, First- Order Language, VDM, …) Formal (Ghezzi): Written down in a formal specification language (e. g. Z, Larch, First- Order Language, VDM, …)  Formal languages have formal, mathematically defined semantics

Functional vs Non-functional functional requirements, (what does it do) functional requirements, (what does it do) non-functional requirements non-functional requirements  reliability, availability, security, accuracy  interface issues, operating constraints,  requirements on development process  quality control  system test procedures  priorities

Properties of Good Requirements Hamlet Understandable Understandable Nonprescriptive Nonprescriptive Correct Correct Complete Set Complete Set Individually Complete Individually Complete Concise Precise Clear Unambiguous Consistent Traceable Modifiable Testable Feasible

Boeing Computer Services Complete Complete Correct Correct Unambiguous, Precise, Clear Unambiguous, Precise, Clear Consistent Consistent Relevant Relevant Testable Traceable Feasible Free of Unwarranted Design Detail Manageable

Example of Concise, not Clear Hamlet The items in tab-separated columns and underscore-separated rows of the output may refer to each other; but no item in (row,column) position (i,j) may refer to another in position (p,q) unless p<i, or if i=p,q<j.

Less concise, but clear Hamlet The output shall consist of rows and columns. Items across each row shall be separated by tabs. There shall be an underscore between rows. When item X refers to item Y, Y must either be in a row above X, or if they are in the same row, Y must be in a column to the left of X. An item may not refer to itself.

Requirements Statement “The system shall …” “The system shall …” Grouped by functionality or subsystem Grouped by functionality or subsystem

Learning to Write Requirements Learn to critique problems. Learn to critique problems. Learn to rework those requirements. Learn to rework those requirements. Learn to critique and rework your requirement statements. Learn to critique and rework your requirement statements. It is difficult to get these right. It is difficult to get these right.

MS Word example: Selecting is the process for designating areas of your document that you want to work on. Most editing and formatting actions require two steps: first you select what you want to work on, such as text or graphics; then you initiate the appropriate action.

Another example: The message must be triplicated. The three copies must be forwarded through three different physical channels. The receiver accepts the message on the basis of two-out- of-three voting policy.

Specification Languages UML (you’ve seen some of this already) UML (you’ve seen some of this already) SDL SDL SCR SCR

SDL: Specification and Description Language Language standard from the International Telecommunications Union Language standard from the International Telecommunications Union Specifies real-time, concurrent, distributed processes Specifies real-time, concurrent, distributed processes Inter-process communication is through unbounded message queues Inter-process communication is through unbounded message queues 3 Diagrams and algebraic specifications 3 Diagrams and algebraic specifications  Algebraic specs here are ADTs

SDL Diagrams System Diagram System Diagram Block Diagram Block Diagram Process Diagram Process Diagram

SCR: Software Cost Reduction Heitmeyer, Navy Research Lab Heitmeyer, Navy Research Lab Models a system as a function mapping monitored environmental (input) variables to (system) controlled (output) variables Models a system as a function mapping monitored environmental (input) variables to (system) controlled (output) variables The function is decomposed into smaller functions, each of which has a table of input/output values The function is decomposed into smaller functions, each of which has a table of input/output values The tables are composed in a data-flow format The tables are composed in a data-flow format

Execution of SCR models Execution is modeled as a flow of variable updates Execution is modeled as a flow of variable updates Outputs of one table may be the inputs to other tables Outputs of one table may be the inputs to other tables When an input value to one table changes, the outputs are propagated to all the other tables When an input value to one table changes, the outputs are propagated to all the other tables Used to clarify and model requirements Used to clarify and model requirements Some work on automated translation of SCR models to code Some work on automated translation of SCR models to code

Classification of Specification Styles Formal vs Informal Formal vs Informal Operational vs Behavioral Operational vs Behavioral  Sometimes it it claimed that behavioral is more abstract than operational.

Example: operational: Let a be an array of n elements. The result of sorting a is an array b of n elements such that the first element of b is the smallest element of a, the second element of b is the smallest element of the array of n-1 elements obtained by removing the smallest element of a, and so on until all n elements have been removed.

Example behavioral (descriptive): The result of sorting a is an array b which is a permutation of a and is sorted.

V&V Validation: did we build the right product? Validation: did we build the right product?  For software, does the system implement the requirements? Verification: did we build the product right? Verification: did we build the product right?  Does each function work correctly? (For software, does it match the specification?)

Techniques for Validation Walkthroughs Walkthroughs Reviews Reviews Models Models  Use cases/Scenarios  Prototypes  Simulations Tracing Tracing

Verification of Specifications Recall that correctness does not imply that the program matches the intentions. Recall that correctness does not imply that the program matches the intentions. Basically there are two ways to verify things: Basically there are two ways to verify things:  observe its behavior and determine if it matches expectations  analyze the properties of the thing that can be deduced from the artifact created

Techniques for Verification Simulation Simulation  Informal: walkthroughs, inspections  Formal: prototyping Static Checking Static Checking  Consistency  Completeness Formal techniques Formal techniques  Model checking  Theorem proving

Verification of Specifications If it’s formal, you might be able to create some sort of interpreter for it. (or a simulation of it). If it’s formal, you might be able to create some sort of interpreter for it. (or a simulation of it). If it’s not formal, then a prototype might be in order. Here, prototyping as a way of verifying the specs. If it’s not formal, then a prototype might be in order. Here, prototyping as a way of verifying the specs. Compare to a bridge: A behavioral description could be the equations governing the support structure. The operational might be a model of the bridge, a mockup. Compare to a bridge: A behavioral description could be the equations governing the support structure. The operational might be a model of the bridge, a mockup.