1. SoITSSpecifications of IT systems? 1 Specifications of IT systems checking and validating Jens Bennedsen and Peter Gorm Larsen (jbb@iha.dk) (pgl@iha.dk)jbb@iha.dkpgl@iha.dk Engineering College of Aarhus

2. SoITSSpecifications for IT systems – Checking and validation 2 Agenda  Potential problems with requirement specifications Reviews Inspections Walkthroughs

3. Examples of requirements SoITSSpecifications for IT systems – Checking and validation 3 7Ambiguous 7Non-verifiable 3 Verifiable The data set will contain an end of file character. The product should have a good human interface. The program shall never enter an infinite loop. The output of the program shall usually be given within 10 secs. The output of a program shall be given within 20secs of event X 60% of the time.

4. Categories of defects of SRSs SoITSSpecifications for IT systems – Checking and validation 4 Omission defect Missing functionality Missing environment Missing performance Missing interfaces Commission defects Ambiguous information Inconsistent information Incorrect fact

5. Contents Check Does the spec contain: Customer, sponsor, background Business goals + evidence of tracing Data requirements (database, i/o formats, comm. state, initialize) System boundaries & interfaces Domain-level requirements Product-level requirements Design-level requirements Specification of non-trivial functions Stress cases & special events & task failures Quality reqs (performance, usability, security...) Other deliverables (documentation, training...) Glossary (definition of domain terms...) SoITSSpecifications for IT systems – Checking and validation 5

6. Structure Check Does the spec contain: Number or Id for each requirement Verifiable requirements Purpose of each requirement Examples of ways to meet requirement Plain-text explanation of diagrams, etc. Importance and stability for each requirement Cross refs rather than duplicate information Index An electronic version SoITSSpecifications for IT systems – Checking and validation 6

7. Create, Read, Update, Delete + Overview SoITSSpecifications for IT systems – Checking and validation 7 Task GuestStayRoomRoom StateServiceService Type BookCUOCOUO CheckInBookedRUUOO CheckInNonBkdCUOCOUO CheckOutUUORU ChangeRoomRROUO RecordServiceOCR PriceChangeCUDO Missing?DDCDRUD

8. SoITSSpecifications for IT systems – Checking and validation 8 Agenda Potential problems with requirement specifications  Reviews Inspections Walkthroughs

9. 9 When are reviews needed? A review is any activity in which a work product is distributed to reviewers who examine it and give feedback. Reviews are useful not only for finding and eliminating defects, but also for gaining consensus among the project team, securing approval from stakeholders, and aiding in professional development for team members. Reviews help teams find defects soon after they are injected making them cost less to fix than they would cost if they were found in test. All work products in a software project should be either reviewed or tested. Software requirements specifications, schedules, design documents, code, test plans, test cases, and defect reports should all be reviewed. Specifications for IT systems – Checking and validation

10. Verification techniques Review Inspection Add-hoc Checklist Scenario Walkthrough SoITSSpecifications for IT systems – Checking and validation 10

11. 11 Deskchecks A deskcheck is a simple review in which the author of a work product distributes it to one or more reviewers. The author sends a copy of the work product to selected project team members. The team members read it, and then write up defects and comments to send back to the author. Unlike an inspection, a deskcheck does not produce written logs which can be archived with the document for later reference. Deskchecks can be used as predecessors to inspections. In many cases, having an author of a work product pass his work to a peer for an informal review will significantly reduce the amount of effort involved in the inspection. Specifications for IT systems – Checking and validation

12. Review versus Inspection Review: Presentation to the Group in each Development Phase Discussion and Coordination with other stakeholders Goal: Clarification and Accept/Reject DecisionGoal: Clarification and Accept/Reject Decision Inspection: Quality Improvement Process to the software project Goal: Defect Detection & Defect PreventionGoal: Defect Detection & Defect Prevention Specifications for IT systems – Checking and validation

13. SoITSSpecifications for IT systems – Checking and validation 13 Agenda What did we look at last week Potential problems with requirement specifications Reviews  Inspections Walkthroughs

14. Inspection Inspections are moderated meetings in which reviewers list all issues and defects they have found in the document and log them so that they can be addressed by the author. The goal of the inspection is to repair all of the defects so that everyone on the inspection team can approve the work product. Commonly inspected work products include software requirements specifications and test plans. SoITSSpecifications for IT systems – Checking and validation 14

15. The inspection team Inspection leader Plans for the inspection, sets the date, invites the participants, distributes the required documents Runs the inspection meeting A recorder Records the results of the inspection Group of inspectors 3 to 10 inspectors Each should ideally represent a different perspective of the work product SoITSSpecifications for IT systems – Checking and validation 15

16. Running an inspection meeting 1.Each inspector prepares for the meeting by reading the work product and noting each defect. A defect is any part of the work product that will keep an inspector from approving it. 2.Discussion is focused on each defect, and coming up with a specific resolution. It is the job of the inspection team to do more than just identify the problems; they must also come up with the solutions. 3.The recorder compiles all of the defect resolutions into an inspection log SoITSSpecifications for IT systems – Checking and validation 16

17. Inspection log example SoITSSpecifications for IT systems – Checking and validation 17

18. Ad-hoc Inspection Based on existing skills with inspection team Looking for omission defects Missing functionality Missing environment Missing performance Missing interfaces Looking for commission defects Ambiguous information Inconsistent information Incorrect fact Wrong section SoITSSpecifications for IT systems – Checking and validation 18

19. Checklist based Inspection Standard list of questions to look for Such lists can for example be found at http://www.opfro.org/index.html?Components/WorkProd ucts/RequirementsSet/SystemRequirementsSpecificatio n/SystemRequirementsSpecificationInspectionChecklist.html~Contents http://www.opfro.org/index.html?Components/WorkProd ucts/RequirementsSet/SystemRequirementsSpecificatio n/SystemRequirementsSpecificationInspectionChecklist.html~Contents Detect the same kind of defects as ad hoc inspection More systematic Typically checklists are specialised to the application domain in which a company work SoITSSpecifications for IT systems – Checking and validation 19

20. Scenario based Inspection Considering different perspectives after each other Data type consistency scenario Identify data objects Determine data type information Data involved in functional requirements Incorrect functionality scenario Identify input and output for all functional requirements Identify system events for all functional requirements Determine any invariant properties Ambiguities and missing functionality scenario Identify precision and response time requirements Identify monitored events per requirement and mode SoITSSpecifications for IT systems – Checking and validation 20

21. SoITSSpecifications for IT systems – Checking and validation 21 Agenda What did we look at last week Potential problems with requirement specifications Reviews Inspections  Walkthroughs

22. Walkthrough An informal way of presenting a technical document The author runs the walkthrough: calling the meeting, inviting the reviewers, soliciting comments and ensuring that everyone present understands the work product Walkthroughs are used when the author of a work product needs to take into account the perspective of someone who does not have the technical expertise to review the document After the meeting, the author should follow up with individual attendees who may have had additional information or insights. The document should then be corrected to reflect any issues that were raised SoITSSpecifications for IT systems – Checking and validation 22

23. SoITSSpecifications for IT systems – Checking and validation 23 Summary What have I presented today? Review defect categories Reviews Inspections Walkthroughs What do you need to do now? Conduct formal inspection of selected specification Document findings with reference to use of relevant articles Prepare and deliver inspection report + conduct inspection meeting on Tuesday Email wishes for subjects for last lecture

24. SoITSSpecifications for IT systems – Checking and validation 24 Quote of the day By Fred Brooks In the ”No Silver Bullet” paper The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements... No other part of the work so cripples the resulting system if done wrong. No other part is as difficult to rectify later.