Project 2 (PRJ2) Software Requirements Specification Ferd van - - PowerPoint PPT Presentation

Project 2 (PRJ2) Software Requirements Specification

Ferd van Odenhoven

Fontys Hogeschool Techniek en Logistiek

February 27, 2013

Ferd van Odenhoven/FHTBM Project 2 (PRJ2) Software Requirements Specification February 27, 2013 1/7

Software Requirements Specification (SRS)

What should such a document contain? Dynamic Analysis!

Use Cases: functional requirements (see library case in MOD1) Business Processes (with ARIS = UML) Scenarios Activity Diagrams (for processes not covered by ARIS diagrams)

Static Analysis

Domain Model: Not in SRS Model Dictionary: ‘entities’ with attributes and actions. Can be added to the SRS.

Analysis and Domain Expert

He might not tell you everything and assume you know that truck drivers can get ill and trucks can have accidents. He might only give answers that should give you a starting point and think you do the rest yourself.

Ferd van Odenhoven/FHTBM Project 2 (PRJ2) Software Requirements Specification February 27, 2013 2/7

Software Requirements Specification (SRS)

What should such a document contain in more detail? Use Cases

high level: HLUC low level: connected to one HLUC Properly numbered and related/grouped to one another.

Use Case Diagram

Keep actors together in (part of) system If diagram >> A4-size: keep use cases DRY → business process per diagram! Group cooperating use-cases in one diagram, surrounded by all relevant actors.

Datamodel dictionary

Entities (objects) = nouns in your case description, relevant for the software Attributes belonging to the entities. Actions that can be applied to the entities, CRUD and the more specific actions.

Ferd van Odenhoven/FHTBM Project 2 (PRJ2) Software Requirements Specification February 27, 2013 3/7

Use Case Diagram

Keep cooperating use cases together in one diagram: no

• vercrowded diagram.

Business process 1 Actor2 Actor1 Use case 3 Use case 1 Use case 4 Use case 2 «includes» «includes»

Ferd van Odenhoven/FHTBM Project 2 (PRJ2) Software Requirements Specification February 27, 2013 4/7

What about testability?

Create a number of concrete scenarios! Concrete scenarios are instances of a use case! Meaning: use realistic data. Not “asdf” or some other keyboard swipe, but “Janssen”. Best case & worst case scenarios. A concrete scenario ≡ test scenario!

You can use them in your acceptance test! You can use them in your GUI test! You can use them in your Unit tests! Use Case

CS = concrete scenario

CS1 CS2 CS3

Ferd van Odenhoven/FHTBM Project 2 (PRJ2) Software Requirements Specification February 27, 2013 5/7

Have a go at IT

Figure: Happy analysing to you!

Ferd van Odenhoven/FHTBM Project 2 (PRJ2) Software Requirements Specification February 27, 2013 6/7

Deliverables

The following documents are requested: A structured SRS document, containing:

all use cases: the functional requirements a model dictionary (useful for domain model & class diagram & database & GUI-design) Non-functional requirements: possibly only a few! (Example: will be coded in java using JEE) Document name: SoftwarerequirementsSpecificationGx.pdf, wherein x after G is the group number! Place it in the requirements folder. Where to put other stuff? That is: material related to brainstorming, customer interview, domain expert interview can be placed in the analysis folder.

Save your concrete scenarios for the moment you are going to make the acceptance test for the customer. Do you know the difference between the domain-expert and the customer?

Ferd van Odenhoven/FHTBM Project 2 (PRJ2) Software Requirements Specification February 27, 2013 7/7