1. Requirement engineering for an online bookstore system
Vahid Jalali
Amirkabir university of technology, Department of computer engineering and information technology, Intelligent systems laboratory, Requirement engineering course, Fall 2007

2. Outline Introduction Overall RE process model Organization type
Elicitation
Specification
Analysis
V&V
Change management
Conclusions
References

3. Introduction
Creating a huge quality software system without requirements engineering disciplines is impossible
Requirements engineering should provide guidelines for these steps
Elicitation
Specification
Analysis
Validation and verification
Change management
In this presentation we review RE techniques we used for requirements engineering for our online bookstore system

4. Spiral model of the RE process

5. Target organization type
There are three kinds of organizations
Acquisition organizations
Supplier organizations
Product companies
our organization is a supplier organization
It responds to acquisition requests from acquisition organizations or higher level supplier organizations
These organizations receive input requirements and develop system requirements in response to them

6. Elicitation Components of requirements elicitation
Application domain
Problem to be solved
Business context
Stakeholder needs and constraints

7. Elicitation (Cont.) application domain understanding
business vocabulary for our online bookstore system
customers and users of the system
understanding stakeholders’ needs
Applied techniques
Document study
Interviews
Prototyping
Brain storming
Use cases
More detailed description for applied techniques
Main use cases of our online bookstore system

8. Elicitation (Cont.) QFD place in requirements elicitation Yes No
Conduct fast meetings
Make list of functions, Classes
Formal prioritization?
Make list of constraints
Yes No
Use QFD
Informal prioritization
Create use cases

9. Specification badly stated requirements can result in
malfunctioning software
software which can not satisfy its users’ needs
We use RUP standards for specifying requirements of our online bookstore
specify functional requirements
SRS
specify non-functional requirements
supplementary specification
We have provided a checklist for SRS document and an exemplary SRS for our online bookstore

10. Specification (Cont.)
Using boilerplates for requirements specification
Problem domain boilerplates
The <stakeholder type> shall be able to <capability>
The <stakeholder type> shall be able to <capability> by <constraint> or <constraint>
The <stakeholder type> shall be able to <capability> by <constraint> and <constraint>

11. Specification (Cont.) Solution domain boilerplates
The <system> shall be able to <function> <object> within <performance> <units>
The <system> shall be able to <function> <object> within <performance> <units> from <event>
The <system> shall be able to <function> <object> every <performance> <units>
The <system> shall be able to <function> in less than <performance> <units>
The <system> shall be able to <function> in less than <performance> <units> in <operational condition>
See the filled boilerplates in our final report document

12. Analysis
The goal of analysis is to discover problems, incompleteness and inconsistencies in the elicited requirements
These are then fed back to the stakeholders to resolve them through the negotiation process
Analysis is interleaved with elicitation as problems are discovered when the requirements are elicited

13. Analysis (Cont.) Requirements Analysis Methods
Structured Analysis
Object Oriented Analysis
Formal Methods
We use Object oriented analysis for our online bookstore because
It is a single paradigm
Facilitates architectural and code reuse
Models more closely reflect the real world
Stability
Increasing productivity
Decreasing analysis activity
Decreasing Complexity in Design
Easier review and verification by customer
Increasing reusability

14. Analysis (Cont.)
Most of the expenses of a software is related to maintenance
OOA decreases maintenance expenses though it may be more expensive in implementation and design phases
See the class diagram for our online bookstore system based on UML class diagrams

15. Validation and verification
Techniques used for validating and verifying our online bookstore system
Requirement reviews
Prototyping
Evolutionary
Acceptance tests
general web application testing checklist
validation verification checklist

16. Change management
We use RUP configuration and change management workflow for change managing of our project

17. Change management (Cont.)
We distinguish 4 traceability paths
Trace top-level requirements into detailed requirements
Trace requirements into design
Trace requirements into test procedures
Trace requirements into user documentation plan
As a tool for supporting change management in our project we have chosen RequisitePro which is of great use in change management process
From use cases to test cases with RequisitePro

18. Conclusions
Creating a huge quality software system without requirements engineering disciplines is impossible
In this presentation we reviewed techniques and guidelines we used for requirements engineering for an online bookstore system

19. References
[1] Requirements Engineering, Elizabeth Hull, Ken Jackson, Jeremy Dick, Second Edition, Springer, 2005.
[2] Pressman Roger, Software Engineering: A Practitioner's Approach, 6th Edition, McGraw-Hill
[3] Use case driven object modeling with UML, D. Rosenberg and M. Stephens, 2007

20. Thanks for your attention