Requirement engineering for an online bookstore system

1. Requirement engineering for an online bookstore system Vahid Jalali Amirkabir university of technology, Department of computer engineering and information technology, Intelligent systems laboratory, http://ceit.aut.ac.ir/islab, 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 Problem to be solved Application domain Stakeholder needs and constraints Business context

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 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