Analysis Best Practices

Functional Requirements

Engage Analysis

August 2015

General characteristics of good requirements

Correct

so that…

they’re free from error and easy to read.

Unambiguous they’re not open to misinterpretation.

Completethey have a value in themselves without unnecessary dependencies on other requirements at the same level.

Consistentthey follow a common set of conventions and are not conflicting with other requirements at the same level.

Feasiblethey can be implemented and are free of unnecessary design detail.

Modifiablethey can be rewritten if necessary without changing the style and structure.

Traceablethey are uniquely identifiable and can be linked to owners, sources, versions, phases as applicable.

Risk-assessedthey are known to be business critical where applicable.

Testable

they contain all necessary information to be tested and verified and their acceptance criteria are appropriate to the level of detail required by acceptance testing.

–

The 5 Cs of Requirements Gathering

Clear

use the active voice; organise them logically; make them standalone

Concise keep it simple; be specific; avoid repetition

Concrete use defined causes and outcomes

Completehave child requirements where necessary; check for all operations and for all outcomes; make them descriptive

Consistentboth from a formatting and a logical perspective; use the same fonts, the same synonyms and the same references

–

Requirements help to understand the behaviour of a system; this is often described by various ‘tasks’ that the system is expected to perform.

The IEE definition for functional requirements is ‘a function that a system or component must be able to perform’.

Functional requirements (behavioural requirements) describe the functionality or services the software should provide. The interaction of the software with its environment inputs, outputs, external interfaces and functions that should not be included in the software.

[From Software Engineering, p67-68 (Khurana, 2009)]

What are functional requirements?

Project pitfalls: the most costly one is always poorly defined requirements, both FRs and NFRs

TIPS: • Keep requirements SHORT• Write ONE LINE per requirement• Use SPECIFIC terms such as must and should• Then PRIORITISE them

Results of poorly defined requirements

Poor stakeholder satisfaction

Software that does not meet Business

Objectives

Difficult technical

challenges

Schedule and budget expansion

Requirements Prioritisation: MoSCoW Approach

Once the reqs have been written, they must be prioritised because different stakeholders cannot always be given what they want immediately (if at all, even).

The MoSCoW approach originated form the Dynamic Software Development (DSDM) Methodology and is used by BAs and stakeholders in order to prioritise requirements in a collaborative fashion.

MoSCoW is a pseudo-acronym for the following:

• Must have • Should have • Could have• Won’t have (but will have in the future: this is used in Agile but is not a negative req. It signposts reqs

that cannot be delivered in the current sprint or release and will most likely be included in the next one).

Must Have

• Requirements that must be included in the final solution

• Must be satisfied because they are critical to the projects success

• Of a high priority• Non negotiable without them the

project is a failure

The HR system “must” store employee leave history

Should Have

• Important to project success but not necessary to deliver in the current delivery

• High priority to be included if possible

• Important and of high value to user

The HR system “should” allow printing of leave allocation

Could Have

• Desirable or nice to have based on time and resource availability on project

• Solution will be acceptable without these requirements

• Could requirements increase customer satisfaction for little development cost

The HR system “could” send out notifications on pending leave

dates

Won’t or Would

• Least critical or not appropriate at that time

• Lowest payback items which do not affect project

• Requested by stakeholders but excluded from the scope for the planned duration

The HR system “won’t” support remote access but will do in the

next release

A req specification is based on two key elements: Functions and Data

Functions – a description of the interactions between the system and its (human and system) actors. An interaction is a sequence of actor inputs (e.g. a user clicking a mouse button) and system outputs (e.g. displaying some data on the user’s screen). Typically the actor is trying to achieve some objective (log in, search for data, update data, perform a calculation and so on).Use Cases are excellent for describing the functions of a system.

Data – a description of the state of the system. The system’s state always has an important effect on its functions. A function which updates the system’s state has a delayed effect in that it affects any other function which outputs the same data.

Functions and data are intertwined and you can’t really describe one without the other.

Data Entry Data Maintenance

Procedural Retrieval Requirements

[Business Analysis 2nd Edition, p173-174 (Paul, Yates, Cadle 2010)]

Which categories may we need or encounter?

So what does it mean really?

Data Entry Data Maintenance

Procedural Retrieval Requirements

Requirements concerned with gathering and recording the data that is required in the solution

Changes to data used in the solution

Business rules related to working procedures

Requests concerned about data, specified reports and responses to techniques

[Business Analysis 2nd Edition, p173-174 (Paul, Yates, Cadle 2010)]

SpecificMeasurableAchievable

RealisticTestable

When in doubt about your requirement, ask yourself some questions…

Is it SPECIFIC? = who/what/where/why identified?Is it MEASURABLE? = how much/how many/how will I know clearly quantified?Is it ACHIEVABLE? = how can the goal be accomplished?Is it REALISTIC? = is it rooted in the real needs of the business?Is it TESTABLE? = can it be tested before going live?

The system will process a maximum of 2,000 orders per hour at peak time, with a minimum of 500 and an average of 900. [GOOD!]

The system will process what the current system processes or more. [BAD!]

Can we have SMART requirements?

Because if they are not specific, measurable, achievable, realistic and testable it will be impossible to prove that the needs of the business and of the system have been met.

The V- Model

Business Case

Requirements

System Design

Unit Design

Build

Unit Testing

System Testing

Acceptance Testing

Benefits

Confirmation

Why should they be SMART?

1.

Retrieval of queued messages: should the source be unavailable, the transaction bus must be able to retrieve all queued messages from all queues as soon as the source is restored.

2.

Processing of unexpected message types: the transaction bus must be able to process all unexpected message types from all the source systems.

3.

Retrieval of messages: the transaction bus must be able to retrieve (=display and present for inspection) all messages in their raw format.

4.

Character symbols for currencies: the system should support the character symbols required for all currencies.

5.

Users must be able to retrieve and access all their transactions for the previous 30 days.

FRs – Some Good Examples (i)

FRs – Some Unclear/Incomplete Examples (ii)

6.

Users should be able to tell what they have bought.

Is it CLEAR, CONCISE, CONCRETE, COMPLETE, CONSISTENT, SPECIFIC, MEASURABLE, ACHIEVABLE, REALISTIC and TESTABLE? Is it in conflict with requirement number 5? It seems straight-forward enough but is it measurable or testable or even specific enough?

7.

Thresholds definition for payment method and payment currencyMaximum amount for payment methodMaximum amount for payment currency

Is it CLEAR, CONCISE, CONCRETE, COMPLETE, CONSISTENT, and SMART? This is incomplete and it lacks validity and clarity. What is the need that the req must express? We have no idea.

8. Edit/Add and delete credit cards Stop ListUser should be able to search by entering the credit card numberTo add new credit card in list, user should enter Credit card to be added to the stop list. System will issue a warning in case the card is already on the stop list

Is it SMART? What is the req truly? This reads a lot like the inkling of a potential test script, except how can our testers write a script if they don’t know what the system must do? If this were the req, they’d have no idea.

9.

Update Payment Order Non-Cash status

Based on the feedback from the Payment Channel the status of the Payment Order NC is changed to paid or failed. For Bank Cheques we receive feedback from CSC, registering the cheque numbers for transactions were a bank cheque has been printed.

The Operator keeps track of paid bank cheques and updates the status of the Payment Order NC accordingly. For failed Payment Order NC from EUROLINE a letter stating the reason for the fail is provided and needs stored for bookkeeping and as an explanation to the subsidiaries.

Bank cheques not possible to deliver to the traveller address are returned to the company and the status is updated to failed.

Payment Channel also report successful Payment Reversal Order NC, which need to be recorded as failed or executed. Changes to Payment Order NC need reported to accounting.

Non-Cash Payment Order NC for bank cheques that cant be stopped are automatically put on hold. For Payment Exception cases a message is triggered to the requester and depending on the nature of the Refund Change Ticket the system considers this the final state or triggers a NC Payment Request automatically.

Input:

Acquirer-Bank statement, Bank cheque printing feedback, Cashed Bank cheque Feedback, CUP chargebacks and rejects

Euroline Payment feedback, Euroline: Feedback Report, JCB chargeback & rejects, Payment Reversal Order NC confirmation

Output:

AUC Payment Feedback, Payment Exception status information

Roles:

Payments operator (accountable)

Is it CONCISE and SMART? Are there too many reqs here, is there a lack of clarity? It must be broken down into many reqs to address different needs and different levels of detail.

FRs – A Classic Example (iii)

10.

Payment Reversal Order NC confirmation

E-mail from the payment channel informing about the status of the Change Refund Order status.

This is just a statement, it isn’t a req.

11.

Credit Note expired amounts

This is a booking voucher which is used at year end closing and contains all funds for failed payments which are expired. Data needs separated per subsidiary.

Is this perhaps a glossary term explanation? It surely isn’t a req.

FRs – Some Plain Bad Examples (iv)