310 likes | 685 Vues
Requirement engineering for an online bookstore system. Vahid Jalali. Outline. Introduction Overall RE process model Organization type Elicitation Specification Analysis V&V Change management Conclusions References. Introduction.
E N D
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
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 Problem to be solved Application domain Stakeholder needs and constraints Business context
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 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