Software Requirements and Specification Review the Specifiction - - PowerPoint PPT Presentation

Software Requirements and Specification

Review the Specifiction

SE3821 - Jay Urbain

Review the Specifiction

1

Reviewing the Specification

2

Reviewing the Specification

3

Releasing the Specification

– At some stage in the requirements process, you will want to release your spec – does not mean it is fully complete. – Prior to releasing your specification, you need to review it. review it. – Specification == whatever collection of requirements you currently have.

4

Quality Gateway

– The Quality Gateway and the specification review work together. – QG tests an individual requirement –

• Ensuring it is correctly stated, unambiguous, within scope,

testable, traceable, and does not have gold plating!

– But what about the spec as a whole?

• Collectively do the requirements tell the whole story?

5

Reviewing the Spec

– Determine whether any requirements are missing. – Prioritize so the builders understand the importance and the urgency of the requirements. – Check for conflicts between requirements that could prevent one or the other from being satisfied. prevent one or the other from being satisfied. – Note to project management:

• Estimate cost
• Evaluate risks.

6

Reviewing the Specification

– Review process follows iterative cycle – until all problems have been resolved. – Note: a flawed spec may indicate that the costs and risks outweigh the benefits.

7

Inspections

– Fagan Inspections – formalized process of ensuring the quality of documents using a checklist:

• Assign a moderator to take responsibility for arranging the

inspection and distributing the materials.

• Give inspectors 2 to 3 days to read the document and

prepare for inspection. prepare for inspection.

• Limit inspections to two hours and no more than two

inspections a day.

• Have between 3 and 8 inspectors.
• Checklist of errors is reviewed with each iteration until they

are gone.

8

Finding Missing Requirements

• Determine if all requirements types appropriate to your

product are present in the spec.

Examples: – Financial product without a security requirement. – Web product without a usability requirement. – Web product without a usability requirement.

• Functional requirements should be sufficient to

complete the work of each use case.

• Look for exceptions to the normal things the product

must do.

• Check each product use case against nonfunctional

requirements – does it have the appropriate qualities?

9

Business Use Cases

• For each business event, you determine the work’s

response – the business use case.

• Missing business use cases results in missing

requirements.

• How to determine if you are missing business use
• How to determine if you are missing business use

cases?

10

Business Use Cases

• How to determine if you are missing business use

cases? – Output of requirements process + system modeling.

11

Business Use Cases

• Confirming the completeness of Business Use Cases:

Input Activity Output 1 Stakeholder Define the Scope Context Diagram 2 Context Diagram, CRUD table, ID business events Event List

12

Custodial processes 3 Event List Model business use cases Scenario 4 Scenario Define the business data Business data model 5 Business data model CRUD check CRUD table 6 Business data model Check for custodial processes Custodial processes

Discovering all Business Use Cases

1) Define the Scope – The scope of work to be studied – Defined by context diagram

13

Discovering all Business Use Cases

2) Identify business events and non-events – If an external event happens, the adjacent system sends a data flow to the work to elicit a response. – Each incoming data flow indicates the potential for an external business event. an external business event. – Outgoing flow are either response to event, or time triggered event. – Once you have linked each boundary data flow to a business event – look for non-events! Example:

• Event: “Customer pays invoice” , but what if the

customer does not pay the invoice?

• Need a new event: “Time to resend invoice.”

14

Discovering all Business Use Cases

3) Model the Business Use Case – Check your already defined business use cases against (updated) scenarios.

15

Discovering all Business Use Cases

4) Define the business data model – ERD, relational model, etc.

– Entities used by the business (nouns)

• Example: accounts, sales opportunities, customers.
• Nouns with a business purpose
• Products or services
• Roles – salesman, manager, employee

– Relationships between entities (verbs)

• EmployeeOf
• CustomerOf

16

Discovering all Business Use Cases

5) CRUD Check – Each class of data must be Created and Referenced. – Build a table to ensure each entity has the appropriate actions performed on it: appropriate actions performed on it:

• Class create, reference, update, delete

17

Discovering all Business Use Cases

6) Check for Custodial Processes – Fundamental processes are connected to the reason for the product’s existence

• Monitor patient,
• Record weather data
• Record weather data
• Schedule delivery

– Custodial processes exist to main (keep custody of) the stored data.

• Change address
• Backup data

– Go through CRUD table and make sure you have enough custodial processes to maintain all of the work’s stored data.

18

Discovering all Business Use Cases

Repeat till done (GOTO 1) Remember:

• Customer value – customer satisfaction rating
• Prioritize Requirements
• Cost, value to customer, time, technological risk, ease
• f business implementation, benefit to business, legal
• bligations.
• Check for Conflicting requirements
• Ambiguity

19

RISK

Risk analysis is not directly connected with requirements.

• Best to have someone other than RA perform risk

analysis – someone trained in risk assessment.

• Risk assessment identifies the risks the project faces

along with the probability of a risk manifesting itself as a along with the probability of a risk manifesting itself as a problem.

• Focus is on show stoppers!

20

RISK

How to identify major risks:

• Purpose of the project

– Reasonable? – Achievable?

• Client, Customer, Stakeholder

– Client a willing stakeholder? – Skin in the game?

• Project Constraints

– Mandated constraints? – Relevant facts and assumptions?

• Functional requirements

– Scope of work? – Scope of product?

• Technological, resource, etc.

21

Effort

Measure required effort

• 1. Not necessarily the responsibility of RA.

22

Summary

Specification Review:

• Access the correctness, completeness, and quality of

the requirements specification.

• Opportunity to measure the value, cost, and risk

attached to building the product, assess whether it is attached to building the product, assess whether it is worthwhile.

23