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

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

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

Spiral model of the RE process

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

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

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

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

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

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>

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

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

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

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

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

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

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

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

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

Thanks for your attention