Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Requirements and Design-Basics of Software Engineering-Lecture Slides, Slides of Software Engineering

This lecture is part of lecture series for Software Engineering course. Prof. Prateek Aron delivered this lecture at Allahabad University. Its main points are: Requirements, Design, Basics, User, System, Functional, Contact, Model, Language, Specifications

Typology: Slides

2011/2012

Uploaded on 07/16/2012

sanaka
sanaka 🇮🇳

4.6

(21)

72 documents

Partial preview of the text

Download Requirements and Design-Basics of Software Engineering-Lecture Slides and more Slides Software Engineering in PDF only on Docsity!

Software Requirements

Descriptions and specifications of a system Last time:  Introduce the concepts of user and system requirements  Described functional / non-functional requirements  To explain two techniques for describing system requirements  To explain how software requirements may be organised in a requirements document COMP201 - Software Engineering 1 This lecture: docsity.com

System Requirements

System Requirements are more detailed

specifications of user requirements:

 They serve as a basis for designing the system;

 may be used as part of the system contract;

 may be expressed using system models (will be

discussed more later).

Problems with Natural Language Specification

Ambiguity  The readers and writers of the requirement must interpret the same words in the same way. Natural Language is ambiguous so this is very difficult  Over-flexibility  The same thing may be said in a number of different ways in the specification which can lead to confusion  Lack of modularisation  Natural language structures are inadequate to structure system requirements

An Example

 Imagine the following example of an informal specification from a critical system [1] :  “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 a two-out-of-three voting policy.”  Questions: Can you identify any ambiguities in this specification?  We will later see some other ways with documenting this example by a Petri net (see Lecture 9). 5 [1] - C. Ghezzi, M. Jazayeri, D. Mandrioli, “Fundamentals of Software Engineering”, Prentice Hall, Second Edition, page 196 - 198 docsity.com

Structured Language Specifications

A limited form of natural language may be used to express requirements  This removes some of the problems resulting from ambiguity and flexibility and imposes a degree of uniformity on a specification  Often best supported using a forms-based approach Special-purpose forms where designed to describe the input, output and functions of a software system

Form-Based Specifications

 Definition of the function or entity  Description of inputs and where they come from  Description of outputs and where they go to  Indication of other entities required  Pre and post conditions (if appropriate)  The side effects (if any)

Tabular Specification

 Tabular Specification is used to supplement natural language.  It is particularly useful when you have to define a number of possible alternative courses of action  This can be thought of as a series of “if statements” to determine the action to be taken upon a certain criteria being met.

Tabular Specification Example

COMP201 - Software Engineering 11 Condition Action Sugar level falling (r2 < r1) CompDose = 0 Sugar level stable (r2 = r1) CompDose = 0 Sugar level increasing and rate of increase decreasing ((r2-r1)<(r1-r0)) CompDose = 0 Sugar level increasing and rate of increase stable or increasing. ((r2-r1) • (r1-r0)) CompDose = round ((r2-r1)/4) If rounded result = 0 then CompDose = MinimumDose docsity.com

Part of an ATM Specification

class ATM { // declarations here public static void main (String args[]) throws InvalidCard { try { thisCard.read () ; // may throw InvalidCard exception pin = KeyPad.readPin () ; attempts = 1 ; while ( !thisCard.pin.equals (pin) & attempts < 4 ) { pin = KeyPad.readPin () ; attempts = attempts + 1 ; } if (!thisCard.pin.equals (pin)) throw new InvalidCard ("Bad PIN"); thisBalance = thisCard.getBalance () ; do { Screen.prompt (" Please select a service ") ; service = Screen.touchKey () ; switch (service) { case Services.withdrawalWithReceipt: receiptRequired = true ;

PDL Disadvantages

PDL may not be sufficiently expressive to express the system functionality in an understandable way  Notation is only understandable to people with programming language knowledge, clients may find this difficult  The requirement may be taken as a design specification rather than a model to help understand the system

Example - PDL Interface Description

interface PrintServer { // defines an abstract printer server // requires: interface Printer, interface PrintDoc // provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter void initialize ( Printer p ) ; void print ( Printer p, PrintDoc d ) ; void displayPrintQueue ( Printer p ) ; void cancelPrintJob (Printer p, PrintDoc d) ; void switchPrinter (Printer p1, Printer p2, PrintDoc d) ; } //PrintServer

The Requirements Document

 The software requirements document is the official statement of what is required of the system developers  Should include both a definition and a specification of requirements  It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it  The requirements document has a diverse set of users as we see in the next slide

Requirements Document

 Specify external system behaviour  Specify implementation constraints  Easy to change  Serve as reference tool for maintenance  Record forethought about the life cycle of the system i.e. predict changes  Characterise responses to unexpected events

Requirements Document

 The level of detail used within the requirements document depends on both the type of system and the development process being used.  For an evolutionary development model the requirements may change many times. In the waterfall model however, it should be more complete since this has more impact on later stages of the software design process.  If the (sub)-system will be developed by an external contractor or it is a critical system, more time needs to be taken on finalizing the requirements document.