Requirements Capture

1. Requirements Capture • From Vision to Requirements • Why it is difficult? • Developers are not users • Inadequate requirements information from users • Individual types of users may have their individual requirements, but not the overall system requirements • Users do not know what a software system can do or cannot do • Users do not know performance issues of required operations.

2. Traditional approach ==> assign analysts to record the requirements • Even with analysts users did not (fully) understand the software until it was completed • Problem: the analyst specification may not be readily transformed into software • Requirements capture remains difficult!

3. The purpose of the requirements workflow • Purpose: to aim development toward the right system. • How: describing the system requirements well enough so that an agreement can be reached between the customers (purchasers and users) and the system developers on what the system should and should not do. • Language: the language of the customer

4. Overview of Requirements Capture • Start with a business model (may already exist) • Next develop a domain model • Sometimes we only have “vague notion” • Eg p. 113 (USDP)

5. List candidate requirements by feature list • Name • Definition • Status (proposed, approved, incorporated, validated) • Estimated cost to implement (resource type and man-hours) • Priority (critical, important, ancillary) • Associated level of risks in implementing the feature (critical, significant, ordinary)

6. Understand system context • Domain modeling • A domain model describes the important concepts of the context as domain objects • Identifying and naming these objects helps us develop a glossary of terms that will enable everyone who is working on the system to communicate better • Helps to identify classes (later) • Business modeling • A business model describes the (existing or perceived) processes of the business of which the software system to be developed will be a part

7. Capture functional requirements • Uses cases • User interface prototypes

8. Capture nonfunctional requirements • What are nonfunctional requirements: • Environmental and implementation constraints • Reliability: availability, accuracy, failure mean time, defects per k-lines/class. • Performance: speed, throughput, response time, memory usage. • Platform dependencies • Maintainability • Extendibility • Eg. p. 116 • How to specify nonfunctional requirements • Use cases with tagged values

9. Resulting artifacts of workflow

10. Understanding the system context using a domain model • A domain model consists of domain objects and their relationships • A domain object represents a thing that exists or event that transpires in environment in which the system works • Types of domain objects: • Business objects: orders, accounts, contracts, … • Real-world objects: cars, trucks, buildings, … • Events (transpired or future): bus arrival, bus departure, dinner, …

11. Eg. p. 120

12. Developing a domain model • Who should do it: • Workshop with domain experts, domain analysts and modeler • How many classes in a domain model? • Modest-sized: 10-50 classes • Simple domain model: glossary of terms • What should be modeled? • The context of the system to be developed, not the system itself • Don’t give too much detail

13. Understanding the system context using a business model • What is a business model? • A business model consists of a business use case model and a business object model. • Business use case model • describes the business process of a company in terms of business use cases and business actors corresponding to business processes and customers. • presents a business system from the usage perspective and outline how it provides value to it users (customers and partners). • Business object model • An interior model of a business • It describes how each business use case is realized by a set of workers who are using a set of business entities and work units, using interaction and activity diagrams.

14. Fif. 6.4 p. 124

15. How to develop a business model • Step 1: Build a business use case model • Step 2: Build an object model for each business use case • Find use cases of the (software) system from a business model • Identify an actor for every worker and business actor (i.e. customer of the business), who will become a user or actor of the system • Identify each worker/business actor's role(s) in each business case realization • Create a tentative use case for each role of each worker and business actor.