Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
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
1 / 28
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
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
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
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
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 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.
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
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 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
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 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
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
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.