RE thesis presentation

A Domain-Specific Verification &
Validation of Software Requirements

By,
Rehman Chughtai
Supervisor,
Dr. Arbi Ghazarian
Master of Computing Studies (MCSt),
College of Technology and Innovation (CTI)
Arizona State University

1 Friday, March 01, 2013

Outline
 Introduction
 Literature review
 Problem statement
 Proposed solution
 Validation of proposed solution
 Findings and contribution
 Conclusion and Future work


Introduction
 Requirements engineering (RE) is a significant step in
Software Development Life Cycle (SDLC)
 “The process of finding out, analyzing, documenting, and
checking the services and constraints is called Requirement
Engineering (RE)” [1]
 Comprehension of requirements can be one of the
major problems faced in developing large and
complex software systems [1,2].
 Defects can propagate from requirements to software


Introduction (continued)

 Fixing defects in later stages of the development
process or after the delivery of the software system
can be difficult and costly[1]
 Verification and Validation (V&V) can reduce the
number of defects



Defects Software requirements

Defects Final Software product

Inspections

Inspections

Software requirements

 Satisfaction of requirements of user and environment, higher
quality of requirements, and cost effectiveness are benefits of
V&V[4,9,10,11]


Verification and Validation (V&V)
 According to Boehm [20],
“Are we building the right product?”, (validation)
“Are we building the product right?”, (verification)
 V&V -Software requirements


V&V -Software requirements
Bahill and Henderson[22] have defined validation of
requirements as making sure that three rules are followed: “
1. the set of requirements is correct, complete, and consistent,
2. a model can be created that satisfies the requirements, and
3. a real-world solution can be built and tested to prove that it
satisfies the requirements.”
Pfleeger and Atlee[23] define verification of software
requirements as “checking requirements specification
document corresponds to requirements definition
document”.
At a broader level, verification of requirements determines that a
work product conforms to requirements, which were initially
defined


Literature review
 Different terms for inspecting requirements
 Requirements validation
 Requirement review
 Requirement inspection


Requirement Review process. Figure adopted from
Kotonya and Sommerville [19]

Humphrey’s inspection
[16]
i. Preparation ii. Inspection iii. Repair and
meeting report

Friday, March 01, 2013 10

Literature review – Inspection techniques
 Three software requirements inspection techniques found in
literature are:
 Ad-hoc methods: with general responsibility of finding defects
within the Software Requirements Specification (SRS)
document, without any specific guidelines.
 Checklists:
Missing Functionality Checklist.
 Are the described functions sufficient to meet the system objectives?
 Are all inputs to a function sufficient to perform the required function?
 Are undesired events considered and their required responses specified?
 Are the initial and special states considered (e.g., system initiation,
abnormal termination)?


 Scenario-based technique
Ambiguities or missing functionality scenario.
1. Identify the required precision, response time, etc. for each functional
requirement.
 Are all required precisions indicated?
2. For each requirement, identify all monitored events.
 Does a sequence of events exist for which multiple output values can be
computed?
 Does a sequence of events exist for which no output value will be
computed?


Problem
 Given a specific domain, like business software, E-
commerce, etc., how to efficiently perform systematic and Domain-
specific Verification and Validation (V&V) of software
requirements.
 In an efficient manner, in terms of defect detection
 Incomplete and defective software requirements are one of principal
basis of software project failure [24]


Problem

Software Inspection
requirements
 Systematic
e.g.
business
 Efficient
software  Domain-specific


Process of proposed solution

Start (1) input (2) process (3) output End

Extraction Classificatio Rule Output
n s


Extraction
 Here the requirement statements are pulled out of SRS document
and input into a database of requirement statements
 It is assumed that each requirement is an atomic statement
 Each requirement statement is manually checked with the
definitions of the term atomic requirement
 Hull et al. [7] have defined atomic as “each statement carries a
single traceable element”


Process (1) - Classification
 requirement statements are classified into different
requirement types.
 “user inputs name and password.” = Data input
 Appendix A, Table 15 has all the Types found in this
project


ID Requirement type Description
1 Data Input Data entered into the system by the actor of the use case
2 Data Output The intermediate or final result of the use case outputted by the system
on the screen/printer. The content of the screens and the rules for
displaying those contents.
3 Data Validation validation of data items inputted by the actors of the use cases
4 Business Logic Application or business logic including calculations
5 Data Persistence All database related operations including reading, updating, inserting and
deleting from/to a database
6 Messaging Sending an email to a party or a message sent from one
system/component of system to another. Also describes the content of
Email.
7 Event Trigger Actor clicks on a menu item or link or button - a command
8 User Interface Flow of application's screen. (Transition between screens). The rules for
Navigation the transitions between screens.
9 User Interface The layout of the page and screen e.g. an input form
10 External Call Calls/messages between different systems./Parameters used to make a
call to system and values received from system.
11 High Level A feature/capability/high level requirement that should be broken down
Requirement into atomic requirements.
12 User Interface User interface/interaction behavior
Logic
13 External Behavior Explains the behavior of an external 3rd party system.

Process (2) - Rules
 After classification, the database is inspected for recurring
relationship between requirement types.
 Rules were developed with those relationships.
 Table 7 has all the 11 rules developed in this project.


ID Rule
1 For every item of type Data Input, there exists at least one item of type
Data Validation
2 For every item of type Data Input, there exists at least one item of type
Data Persistence
3 For every item of type Data Validation, there exists at least one item of type
Data Output
4 For every item of type Event trigger, there exists at least one item of type
other requirement
5 For every requirement of type Data input, all the input data items for the
requirement should be explicitly described
6 For every requirement of type Data output, all the output data items for the
requirement should be explicitly described
7 For every use-case/feature There exists at least one requirement of type
data validation
data input.
data output.
Business Logic.
data persistence.

Application of rules (1)

Rule Software output
requirements

Is the
Manually
apply the relationship/condition
rule defined in rule exits
or not ?


Application of rules (example)

Rule1: “For every item of type Data Input, there exists at
least one item of type Data Validation”

Requirement: “user enters email address in the page.”

Output: This data input requirement is missing the related
data validation requirement.

Assuming that the related data validation is not specified in the requirements
document, then the following output is resulted by applying rule 1.


Output
 With the findings by application of rules
 A report mentioning possible defects in the SRS and other
data is generated as output of the algorithm.


Defect Detection Rate (DDR)


Number of real defects = number of found defects – false positives

Ranking of rules
# of false Defects
Rank Rule ID # of rule application # of warnings DDR Precision
positives found

1 7 51 48 0 48 94.11% 100.00%

2 3 2 1 0 1 50% 100.00%

3 11 51 25 2 23 43.13% 92.00%

4 8 51 21 3 18 35.29% 85.71%

5 10 51 20 3 16 33.33% 80.00%

6 1 72 66 43 23 31.94% 34.84%

7 6 57 17 0 17 29.82% 100.00%

8 9 51 19 3 16 29.41% 84.21%

9 2 72 53 35 18 25.00% 33.96%

10 5 56 12 0 12 21.42% 100.00%

11 4 37 3 0 3 8.10% 100.00%

27 Total 551 283 89 194 Friday, March 01, 2013
--- ---

Findings and contributions
 This thesis reviews and briefly compares the three software
requirements inspection techniques
 A new systematic (algorithmic) inspection technique is
proposed
 The new inspection technique is domain-specific


Conclusion and Future work
 We found that a domain-specific systematic technique can
be better and efficient for performing software
requirements inspection.

 This thesis focused on software requirements of business
software, other domains can be focused by future efforts.

 The set of rules for software requirement inspection
developed during this project can be improved and new
rules can be added to the set.


Questions ?


References
 [1] Ian Sommerville, Software engineering, 8th ed. Essex, UK: Pearson
Education Ltd., 2007.
 [2] Roger S. Pressman, Software engineering A practitioner's approach, 7th ed.
New york, USA: Mc Graw-Hill, 2010.
 [4] B. Nuseibeh and S. Easterbrook, "Requirements engineering: a roadmap," in
ICSE '00 Proceedings of the Conference on The Future of Software
Engineering, New York, 2000, pp. 35-46.
 [7] E. Hull, K. Jackson, and J. Dick, Requirements engineering, 2nd ed. london,
UK: Springer Verlag, 2005.
 [9] Betty H. C. Cheng and Joanne M. Atlee., "Research directions in
requirements engineering," Future of Software Engineering, 2007.FOSE'07, pp.
285-303, May 2007.
 [10] M. Sagheb-Tehrani and A. Ghazarian, "Software development process:
strategies for handling business rules and requirements," ACM SIGSOFT
Software Engineering Notes, vol. 27, no. 2, pp. 58-62, March 2002.
 [11] Ian Sommerville and Pete Sawyer, Requirements Engineering: A good
practice guide. West Sussex, UK: John Wiley & sons Ltd., 1997.

References
 [16] Watts S. Humphrey, A discipline for software engineering.
Reading, Mass., USA: Addison-Wesley, 1995.
 [19] G. Kotonya and I. Sommerville, Requirements engineering. West
sussex, UK: Wiley Chichester, 1998.
 [20] B.W. Boehm, "Verifying and validating software requirements and
design specifications," IEEE Software, vol. 1, no. 1, pp. 75-88, January
1984.
 [22] A. Terry Bahill and Steven J. Henderson, "Requirements
development, verification, and validation exhibited in famous failures,"
Systems engineering, vol. 8, no. 1, pp. 1-14, 2005.
 [23] Shari Lawrence Pfleeger and Joanne M. Atlee, Software Engineering:
Theory and Practice, 4th ed. New Jersey, USA: Pearson Higher
Education, 2010.
 [24] H.F. Hofmann and F. Lehner, "Requirements engineering as a success
factor in software projects," IEEE Software, vol. 18, no. 4, pp. 58-
66, July/August 2001.


RE thesis presentation

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to RE thesis presentation

Similar to RE thesis presentation (20)

Recently uploaded

Recently uploaded (20)

RE thesis presentation