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 overcrowded diagram. Business process 1 «includes» Use case 3 Use case 1 «includes» Use case 2 Actor1 Actor2 Use case 4 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 CS1 CS2 CS3 CS = concrete scenario 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
Recommend
More recommend
