Why Use Prototypes/Simulations?

Prototyping is an excellent analysis technique for software development because it allows the business stakeholders, specifically the software users, to see the software design before it is built. Business stakeholders can easily decide if the design contains the necessary data components, has meaningful labels and descriptions, and make specific suggestions about the placement of screen items and aesthetics. A prototype is also an excellent requirements presentation deliverable for IT developers because they can see exactly what is to be built.

Other Techniques Event Modeling

Identifying and analyzing events provides another valuable requirements perspective. An event is something that happens outside a business area, to which the business area must respond. The responses to events are business processes, so this technique is an alternative approach to identifying business processes. Various methodologists have named several types of events; external and temporal (driven by time) are the most commonly used (Yourdon, 1988). Events are named with the external agent who initiates them (e.g., customer places an order).

Entity State Transition/uml State Machine Diagrams

The state transition analysis technique recommends that the analyst think through all of the states a particular entity or object may be in. A state is a stage in the behavior pattern of an entity (Ambler, 2005). Example states for the entity ORDER would be new, paid, verified, shipped, etc. State transition analysis requires the analyst to think through all of the states in which an entity can exist. Thinking about each state helps to identify processes (how does the state change), additional data, and business rules.

Object Modeling/Class Modeling

Object modeling and class modeling are UML/OO techniques for understanding a business or designing a system. The object or class represents a group of items that are important to the business. The concept of an object or class is broader than that of an entity. The object or class represents not only data but also processes (called behaviors or methods) combined into one requirements component. Object modeling and class modeling are used extensively for software design. These techniques have been used occasionally to elicit and present business requirements.

User Stories

User stories are a relatively new requirements technique derived from use cases. A user story is a specific description of something the software needs to do. User stories are used by some of the agile approaches to software development and with extreme programming (www.extremeprograming.org) to quickly gather requirements. The stories are usually documented very informally on index cards and not maintained as development progresses. They are not intended to capture detailed requirements. They just provide the overall needs of the software for use in prioritization and estimating. More detailed requirements are discussed by the developer and the user as the software is built. Read User Stories Applied by Mike Cohn (2004) to learn about user stories.

Traceability Matrices

A powerful analysis technique is traceability or the linking of requirements. By identifying which requirements components are related to each other, along with any characteristics about the relationship, the analyst will find missing or inconsistent pieces. Almost any two requirements components can be linked. Deciding which links will be useful for each project depends on the project type and risks.

As business requirements are further detailed in functional and technical requirements, they should be traced. When a business stakeholder describes a core business process like RECORD ORDER and the team designs a Web data entry page to allow customers to enter their order information, the business requirement RECORD ORDER is linked to the Web page design. Every component of the completed solution can be traced back to a business requirement. See Table 6.4 for an example of a traceability matrix.

Table 6.4: Sample Traceability Matrix
Prototype
Business Process	Web Order Page	Payment Page	Confirm Page
Record order	X		X
Accept payment		X	X
Check inventory	X

Traceability is an important concept for BAs to understand because recognizing that requirements are related to other requirements is critical to complete understanding. Thinking about traceability helps develop complete requirements. When you identify a new requirement, ask questions about possible related components.

The most common link is referred to as the CRUD matrix: the link between data and process. The CRUD matrix assesses how each data component is affected by each process. CRUD (create, read, update, delete) refers to the actions that a process may take on data. The CRUD matrix may be built on high-level data and process components (entities and business processes) or detailed components (attributes to use cases or screens). See Table 6.5 for an example of a CRUD matrix.

Table 6.5: Sample CRUD Matrix
			Data
		Employee			Paycheck
Process	Number	State Withholding Percentage	State Withholding Amount	Date	Gross Wage Amount	Net Wage Amount
Calculate gross wages	R			C	C
Calculate state withholding	R	R	C		R
Calculate fed withholding	R				R
Calculate net wages	R					C