SOFTWARE REQUIREMENTS ENGINEERING LECTURE # 13 REFINING...
Transcript of SOFTWARE REQUIREMENTS ENGINEERING LECTURE # 13 REFINING...
SOFTWARE REQUIREMENTS ENGINEERING
LECTURE # 13
REFINING THE SYSTEM DEFINITION (SOFTWARE REQUIREMENTS SPECIFICATION)
Engr. Ali Javed 10th July, 2013
Instructor Information
Engr. Ali Javed
2
Course Instructor: Engr. Ali Javed
Assistant Professor
Department of Software Engineering
U.E.T Taxila
Email: [email protected]
Website: http://web.uettaxila.edu.pk/uet/UETsub/perSites/[email protected]
Contact No: +92-51-9047747
Office hours:
Monday, 09:00 - 11:00, Office # 7 S.E.D
Lab Instructor: Engr. Asra, Engr. Sobia
Presentation Outline 3
Requirements Specification
Writing Requirements
Modern SRS Package
Software Requirements Specification Template/Package
Technical methods for Requirements Specification
Pseudo code
Finite state machines
Decision trees
Object Oriented Modeling Class Diagram
Sequence Diagram
Entity-relationship models and many others.
Quality Measures of Software Requirements
Engr. Ali Javed
4
Technical Methods for Requirements Specification
Engr. Ali Javed
Technical Methods for Requirements
Specification 5
Technical methods for specifying requirements are appropriate when the
requirement description is too complex for natural language or if you cannot afford
to have the specification misunderstood.
Technical methods include
Pseudo code
Finite state machines
Decision trees
Object Oriented Modeling
Entity-relationship models and many others.
Engr. Ali Javed
Light Box Example 6
The Requirements Specification of the following features have been written in the natural language style, which are::
After On pushed but before Off pushed, system is termed "powered on."
After Off pushed but before On pushed, system is termed "powered off,―
Since most recent On press, if Count has been pressed an odd number of times, Odd shall be lit
Since most recent On press, if Count has been pressed an even number of times, Even shall be lit
If either light burns out, the other light shall flash every 1 second.
Engr. Ali Javed
Pseudo code [2] 7
Pseudocode is an artificial and informal language that helps programmers develop algorithms
An attempt to combine the informality of natural language with the strict syntax and control
structures of a programming language.
In the extreme form, pseudo code consists of combinations of:
Imperative sentences
A limited set, typically not more than 40–50, of "action-oriented" verbs from which the sentences must be
constructed
Decisions represented with a formal IF-ELSE-ENDIF structure
Iterative activities represented with Loops like DO-WHILE or FOR etc.
Engr. Ali Javed
Pseudo code 8
Example of pseudo code
If student's grade is greater than or equal to 60
Print "passed"
else
Print "failed"
end
Engr. Ali Javed
Pseudo code 9
Example of pseudo code
The algorithm for glowing the Even and Odd lit from the Box example is:
Set COUNT (x)=0
FOR each INPUT X (Button Press)
IF COUNT / 2 == 0
THEN SWITCH ON Even Lit
ELSE
SWITCH ON Odd Lit
END
Engr. Ali Javed
Finite state machines 10
Sometimes it's convenient to look the system as a "proposed machine that can be in only
one of a given number of 'states' at any specific time".
In response to an input, such as data entry from the user or an input from an external
device, the machine changes its state and then generates an output or carries out an action.
Both the output and the next state can be determined exclusively on the basis of understanding
the current state and the event that caused the transition.
In that way, a system's behavior can be said to be deterministic; we can mathematically
determine every possible state and, therefore, the outputs of the system, based on any set of
inputs provided.
Engr. Ali Javed
Finite state machines 11
A popular notation for FSMs is the state transition diagram.
In this notation, the boxes represent the state the device is in, and the arrows represent
actions that transition the device to alternative states.
Figure 1 illustrates state transitions for the light box described earlier.
Figure 1:: Example of a state transition diagram Engr. Ali Javed
Object Oriented Modeling 12
If the requirements that must be refined involve a description of the structure and
relationships among entities within the system, it's often beneficial to use Object Oriented
Models to fully describe the behavior of the system
These diagrams are becoming the part of the Requirement Specification document because
of the popularity of OOD, OOP and the adoption of UML as a standard
Examples
Class Diagram
Sequence Diagram etc.
Engr. Ali Javed
Entity-relationship models [3] 13
If the requirements within a set involve a description of the structure and relationships among
data within the system, it's often convenient to represent that information in an entity-relationship
diagram
Entity–relationship model (ER model) is a data model for describing a database in an abstract
way.
Note that the ERD provides a high-level "architectural" view of the data.
ERD has the potential disadvantage of being difficult for a non-technical reader to understand.
Engr. Ali Javed
Entity-relationship model of HRMS 14
Engr. Ali Javed
Decision Tables and Decision Trees 15
It's common to see a requirement that deals with a combination of inputs; different combinations
of those inputs lead to different behaviors or outputs.
Suppose, for example, that we have a system with five inputs—A, B, C, D, and E—and we see a
requirement that starts with a pseudo code-like statement: "If A is true, then if B and C are also
true, generate output X, unless E is true, in which case the required output is Y.―
The combination of IF-THEN-ELSE clauses quickly becomes twisted, especially if, as in this example,
it involves nested IFs.
Typically, non-technical users are not sure that they understand any of it, and nobody is sure
whether all the possible combinations and permutations of A, B, C, D, and E have been covered.
The solution in this case is to list all the combinations of inputs and to describe each one explicitly
in a decision table.
Engr. Ali Javed
16
In our example, if the only permissible values of the inputs are "true" and "false," we have
2^5, or 32, combinations. These can be represented in a table containing 5 rows—one for
each input variable—and 32 columns.
Alternatively, a decision tree can be drawn to portray the same information.
Figure 2:: Example of a graphical decision tree Engr. Ali Javed
Decision Tables and Decision Trees
17
Quality Measures of Well Documented
Software Requirements
Engr. Ali Javed
Quality Measures 18
Correct
Un-ambiguous
Complete
Consistent
Verifiable
Modifiable
Traceable
Engr. Ali Javed
C Stated
Requirements
B A
User Needs
Correct Requirements
A set of Requirements is Correct if an only if every requirements stated therein
represents something required of the system to built
19
Engr. Ali Javed
Un-Ambiguous Requirements 20
A Requirement is unambiguous if an only if it can subject to only one interpretation
Although correctness is obviously a key concern in any requirement, ambiguity often
turns out to be a larger problem
If a statement of requirements can be interpreted differently by the developers,
users and other stakeholders in the project, it’s quite possible to build a system
that’s completely different from what the user had in mind
Engr. Ali Javed
Completeness of the Requirements Set 21
A set of Requirements is complete if an only if it describes all significant
requirements of concern to the user, including requirements associated with the
functionality, performance, design constraints, attributes, or external interfaces.
Completeness of functional requirements can be verified by using Omission testing
which is achieved through Prototyping
Completeness of Non-functional requirements can be verified by using static
testing techniques like Inspection in which each non functional requirement can
be checked against a checklist.
Design Constraints can also be checked through static testing techniques
Engr. Ali Javed
Consistency in the Requirements Set 22
A Requirement set is consistent if an only if no subset of individual requirements
describe within it are in conflict with one another.
The conflicts can take various forms and are visible at various levels of detail.
One part of the requirement can say ―if A occurs then carry out action B, whereas
at another part of the requirements might say,―if A occurs then carry out action C.
Consistency in the Requirements Set can be checked through careful manual
review and analysis of the complete set of requirements (static testing techniques)
Engr. Ali Javed
Verifiable Requirement 23
Requirements must be verifiable or testable
A Requirement is verifiable in the aggregate if an only if each of the component
requirements contained within it is verifiable
It is necessary to define requirements so that we can later test them and determine
whether they were achieved.
It is the responsibility of the testing and quality assurance personnel to create the
appropriate test procedures to carry out the verification once the software has been
developed
Engr. Ali Javed
Modifiable Requirements Set 24
A Requirement is modifiable if an only if its structure and style are such that any changes to the
requirements can be made easily, completely, and consistently, while retaining the existing
structure and style of the set.
This requires that the containing package have minimum redundancy and that it be well organized.
Requirements will be modified, whether anyone likes it or not; the alternative is a frozen
requirements package which is equivalent to a non existing package and a failed project.
Engr. Ali Javed
Traceable Requirements 25
A Requirement is traceable if an only if the origin of each of its component requirements is
clear and if there is a mechanism that makes it feasible to refer to that requirement in future
development efforts.
This means that the requirements are identified with unique numbers or labels
Refers to ability to describe and follow the life of a requirement, in both a forwards and
backwards direction
Requirements traceability information can be kept in traceability tables, each table relating
requirements to one or more aspects of the system
Engr. Ali Javed
Understandable Requirements 26
A Requirement is understandable if both the user and the developer communities are able to
fully understand the individual requirements and the aggregate functionality implied by the set.
Vision document was much abstract and in less technical terms but later on in SRS the document
gets more detailed and the use of the technical terms increases
So the writer needs to understand the vocabulary and culture terms for the audience
To make users understand the document, usecase diagrams or other technical ways just
discussed earlier can be used.
Engr. Ali Javed
References 27
1. Managing Software Requirements: A Use Case Approach, Second Edition By
Dean Leffingwell, Don Widrig, Addison- Wesley
2. http://www.unf.edu/~broggio/cop3530/3530pseu.htm
3. http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
Engr. Ali Javed
For any query Feel Free to ask 28
Engr. Ali Javed