Requirements and Specifications

Question 1

Requirements vs Specification

Answer 1

Requirements:

• define what an application must do or allow to satisfy one or more business objectives.
• each requirement establishes behavior that helps to satisfy an objective
• establish expectations for application behaviour

e.g. “Ensure that requests are logged against the correct cost center”.
“Allow customers to submit an accident report on-line”.

Specifications:

• defines how an application will satisfy a requirement.
• sometimes refered to as a “use case” or “user story”, depending upon the project methodology in use

e.g. For our purchase request requirement, we could write a UI (user interface) specification to describe a drop-down list of allowed cost centers, with the default value determined from the requestor’s account information.

Question 2

good requirement?

Answer 2

1. Verifiable.
   
   2. Clear and concise.
   3. Complete.
   4. Consistent.
   5. Traceable.
   6. Viable.
   7. Necessary.
   8. Solution-free.

Verifiable
Include information that allows someone to test the requirement in our application. Establish a testable condition, against which we can compare our application in a way that doesn’t compromise the integrity of either the application or its data.

Clear and Consise

• keep requirements to a maximum of 30 to 50 words, and write them so they can be understood easily by non-technical individuals.
• use unambiguous language to avoid misinterpretation, and avoid any definitions, descriptions, and justifications.
• use positive language as often as possible, rather than negative language.
• describe what the application should do or allow, rather than what it shouldn’t .

Complete
Provide all of the information necessary to define the corresponding feature(s) (say: feature or features). Clearly define a benchmark to which we can compare the resulting configured rule(s) (say: rule or rules).

Consistent
Write the requirement so that it does not conflict with or contradict other requirements. Use the same terminology across all of requirements to avoid any misunderstandings. Adhere to organizational standards for all descriptions, such as user roles or tasks.

Traceable
Provide a unique identifier for each requirement, and link requirements to the corresponding specification, rule, and test script. This allows a project manager to verify that the requirement has been satisfied in the application.

Viable

• must be realistic
• does not rely on non-existent technology or resource skills
• can be satisfied within the scope of application development and the project schedule and budget, using available technology and staff.

Necessary
- describes behaviour critical to the operation of the application
- omitting the requirement may lead to a deficiency within the application.
The requirement should state behavior that is essential to the operation of the application. It describes functionality that end users will use, and it must be satisfied to meet the business objectives.

Solution-free
Avoid mention of any possible solution. This allows the business or system architect responsible for satisfying the requirement to decide how best to achieve the desired behavior. Any approach to satisfying the requirement should be part of the specification.

Question 3

Requirement categories

Answer 3

Business Rule, Change Control, Enterpise Standard, Functional, and Non Functional.
• Business rule requirements describe the processing logic of our case. We typically associate these requirements with a particular specification or step in the process – either manual or automated – to identify desired system behavior.
• Change control requirements document a change to an application, either before or after release.
• Enterprise standard requirements document any enterprise- or industry-wide standard to which our application must adhere, such as a specific data format for information.
• Functional requirements identify a task that the system needs to perform or identify a system task that supports case processing. Functional requirements are similar to business rule requirements, but typically describe an automated system function, such as data manipulation, rather than a process step.
• Non-functional requirements identify overall qualities desired for the system, such as performance expectations.
We can define additional categories as needed, though these standard categories are almost always sufficient for a project.

Question 4

Good specification

Answer 4

A good specification answers five (5) basic questions: 
	• Who?
	• What?
	• When?
	• How?
	• Why?

Who
Identify the party responsible for performing the work or task

What
What type of work is each actor performing? We ask “what” to identify the task to perform.

When
When does the actor perform the work? Asking “when” allows us to identify where within the case lifecycle that the action should occur.

How
How does the actor perform this work? Do we want to present options in a list, or as check boxes? What is the data source: a database, or user entry? What are the conditions and results of our decision? Asking “how” helps us to describe the data elements, data exchanges, decision logic, or user interface design to configure.

Why
Identify the reason why the actor performs the work.
Why does the actor perform this action? Do we need to request information in a specific order? Must they comply with a specific business policy or regulation?

Question 5

Business vs Atomic use case

Answer 5

Business:
what it covers: entire process or flow
whom it involves: multiple actors with change of control
why we use it: document the steps in the process

Atomic:
what it covers: a single step in a process
whom it involves: one actor, no change of control
why we use it: document the behaviour of the step

Question 6

Requirement fields

Answer 6

• Requirement ID
• Ruleset+version
• Category (Business Rule, Change Control, Enterprise Standard, Functional, Non Functional)
• Importance (Critical, Very Important, Important, Desirable, Useful)
• Status (New, InProgress, Pending - Deferred, P - Blocked, P - Details, P - Development, Complete, Withdrawn)
• External Req ID
• Short description
• Long description

Question 7

Specification fields

Answer 7

• Application
• Case/Supporting Type
• Ruleset+version
• Name
• Short description
• Status (New, InProgress, Pending - Deferred, P - Blocked, P - Details, P - Development, Complete, Withdrawn)
• Type (Alternate Path, Correspondence, Decision, Entiry flow, Human based step, Integration, Primary path, Report, Starting screen, Sub process, Automated step)
• Complexity (Low, Medium, High)
• Attachments
• Business Objective
• Trigger
• Format (User story, Use case)
• Actors
• Linked requirements
• SMEs
• Pre- and Post conditions

Question 8

Decision/Assignment specifications?

Answer 8

Assignment specification:
Describe assignment behaviour (routing, setting property value)

Decision specifications:

• describe decision flow behaviour
• capture all of the conditions and results of the decision-making process
• correlate each result with the corresponding condition
• applied to decision shapes in flows
• can reference requirements as any other type of specification

If our decision is not used to direct flow processing – for example to determine a value in a declarative expression, or to direct assignment routing, or to display or hide content in our UI – then add the decision behavior to the appropriate assignment or flow action specification.