Software Requirements and Specification Review the Specifiction - PowerPoint PPT Presentation

Software Requirements and Specification Review the Specifiction Review the Specifiction SE3821 - Jay Urbain 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, ID business events Event List CRUD table, Custodial processes 3 Event List Model business use Scenario cases 4 Scenario Define the business Business data model data 5 Business data CRUD check CRUD table model 6 Business data Check for custodial Custodial processes model processes 12

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 of business implementation, benefit to business, legal obligations. • 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? 21 • Technological, resource, etc.

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