Software Requirements

Transcription

1 Software Requirements Requirements Engineering, Requirements Analysis B. Lund. (2013). Lunch. Available: Hans-Petter Halvorsen

2 Software Requirements Requirements for a software system set out what the system should do and define constraints on its operation and implementation

3 Requirements: The statements that describe what the software system should be but not how it is to be constructed. Requirements Engineering: A set of activities related to the development and agreement of the final set of requirement specifications. Steps in the Requirements Engineering Process:

4 Requirements Engineering Software Requirements

5 Requirements Engineering

6 What is Requirements Engineering? Requirements is the bridge between the real world and the software system User World Requirements Software System An Introduction to Requirements Engineering:

7 Requirements Engineering What the Customer got What the Customer really needed

8 Software Requirements & Design Requirements (WHAT): WHAT the system should do Describes what the system should do with Words and Figures,etc. SRS Software Requirements Specification Document Software Design (HOW): HOW it should do it Examples: GUI Design, UML, ER diagram, CAD, etc. SDD Software Design Document Note! Many don't separate SRS and SDD documents, but include everything in a Requirements & Design Document (SRD document). In practice, requirements and design are inseparable.

9 Customer Requirements User Requirements System Requirements B. Lund. (2013). Lunch. Available: Communication between Customers/Stakeholders and Software/IT people is demanding! What does the Customers really want/need? Functional Requirements Non-Functional Requirements

10 6 dimensions of Requirements There are six main categories of information that must be addressed in the Requirements specifications: Individual functionality is the the natural starting point. Ask the Users and Customers what their problems are in terms of what functions need to be implemented in the product.

11 Who will read it? Users of a requirements document System customers Managers Specify the requirements and read them to check that they meet their needs. Customers specify changes to the requirements. Use the requirements document to plan a bid for the system and to plan the system development process. System engineers Use the requirements to understand what system is to be developed. System test engineers Use the requirements to develop validation tests for the system. System maintenance engineers Use the requirements to understand the system and the relationships between its parts. I. Sommerville, Software Engineering: Pearson, 2010.

12 The Development Process involves different phases The Development Process The Requirements may be given by the Customer Are the Design wrong? Go back and correct it! Requirements Design Implementation Testing In this case the overall Requirements are given by the Teacher in the Assignment. The details are written by you! The Design phase is important, but make sure you have time left for all the other tasks as well) Errors? Improve your code and fix the bugs Make sure everything work as expected When you are finished, you deploy and test the solution on the Customer Site Deployment

13 Why spend time on Requirements Analysis? Cost per defects and changes Software Development Life Cycle (SDLC)

14 Software Requirements Hans-Petter Halvorsen

15 Software Requirements Typical written by the Customers Typical written by Software Architects, etc. High-Level Requirements Detailed Requirements.

16 High-Level Requirements vs. Detailed Requirements

17 High-Level Requirements WHAT should the system do? Who should use the system What is the purpose with the system? Performance What parts should the system consists of What Platforms should be used (PC, Tablet, Web?,...) etc. Use Words and Figures in order to describe these Requirements

18 Detailed Requirements and Design What Platforms should be used (Windows, ios,...) in more detail Tools and Languages Software Architecture () Frameworks (.NET, ASP.NET,...) Detailed GUI design sketches UML Diagrams ER (Database) Diagrams CAD Drawings etc.

19 Software Requirements Categories Requirements Requirements User Requirements System Requirements Functional Requirements Non-Functional Requirements

20 Software Requirements Categories Requirements: Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. User Requirements System Requirements Functional Requirements Non-Functional Requirements Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. May state what the system should not do. A structured document setting out detailed descriptions of the system s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor. Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Often apply to the system as a whole rather than individual features or services.

21 User vs. System Requirements User Requirements: Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. System Requirements: A structured document setting out detailed descriptions of the system s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor. I. Sommerville, Software Engineering: Pearson, 2010.

22 User vs. System Requirements Who will read them? User requirements Client managers System end-users Client engineers Contractor managers System architects System requirements System end-users Client engineers System architects Software developers I. Sommerville, Software Engineering: Pearson, 2010.

23 User vs. System Requirements User requirement definition Examples: 1. The MHC-PMS shall generate monthly management reports showing the cost of drugs prescribed by each clinic during that month. System requirements specification 1.1 On the last working day of each month, a summary of the drugs prescribed, their cost and the prescribing clinics shall be generated. 1.2 The system shall automatically generate the report for printing after on the last working day of the month. 1.3 A report shall be created for each clinic and shall list the individual drug names, the total number of prescriptions, the number of doses prescribed and the total cost of the prescribed drugs. 1.4 If drugs are available in different dose units (e.g. 10mg, 20 mg, etc.) separate reports shall be created for each dose unit. 1.5 Access to all cost reports shall be restricted to authorized users listed on a management access control list. I. Sommerville, Software Engineering: Pearson, 2010.

24 Functional vs. Non-Functional Requirements Functional Requirements Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. May state what the system should not do. Non-Functional Requirements Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Often apply to the system as a whole rather than individual features or services. I. Sommerville, Software Engineering: Pearson, 2010.

25 Functional Requirements Describe functionality or system services. Depend on the type of software, expected users and the type of system where the software is used. Functional user requirements may be high-level statements of what the system should do. Functional system requirements should describe the system services in detail. I. Sommerville, Software Engineering: Pearson, 2010.

26 Non-Functional Requirements These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. Process requirements may also be specified mandating a particular IDE, programming language or development method. Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless. I. Sommerville, Software Engineering: Pearson, 2010.

27 Non-Functional Requirements Examples: Product Requirement: The system shall be available to all clinics during normal working hours (Mon Fri, ). Downtime within normal working hours shall not exceed five seconds in any one day. Organizational Requirement: Users of the system shall authenticate themselves using their health authority identity card. External requirement: The system shall implement patient privacy provisions as set out in HStan priv. I. Sommerville, Software Engineering: Pearson, 2010.

28 Exercise - Requirements Create User and System Requirements for your system Create Functional and Non-Functional Requirements for your system

29 Software Design Hans-Petter Halvorsen

30 System Overview and Architecture The big picture Give an introduction to your system and the main pieces, and how they are connected, etc. MS PowerPoint or Visio are good tools to use

31

32 Design B. Lund. (2013). Lunch. Available: GUI Design and Technical Design (UML, ER diagram, CAD)

33 GUI Design Sketches Mockups

34 Flow Charts High-Level Flow Charts makes it easy to see how the system shall work The Flow Charts should be understood by non-programmers like the Stakeholders, Project Managers and Customers Note! Later you may create more detailed diagrams such as UML diagrams, etc. MS Visio or MS PowerPoint has built in features for creating Flow Charts

35 Flow Chart Symbols

36 Interface specifications? Module 1 Module 2 How do different modules interact with each other? What is input and output from the different Modules??? Module 3

37 UML Unified Modelling Language Hans-Petter Halvorsen

38 Why use UML? Design Forward Design: doing UML before coding. Makes it easier to create the code in a structured manner Backward Design: doing UML after coding as documentation When doing changes in the Design, make sure to update the Code according to the new Design Code Some Tools can Auto generate Code from UML diagrams When doing changes in the Code, make sure to update the UML Diagrams

39 Types of UML Diagrams

40 Use Case Diagram

41 Sequence Diagram

42 SRS Document Hans-Petter Halvorsen

43 Typical Documentation Project Management (Gantt Chart, etc.) Start Time Finish 1. Planning 2.Requierements /Design (The stakeholders, the software team; architects, UX designers, developers) 2. Testing (QA people) 3. End-user Documentation (The people that shall actually use the software) Development Plan High-Level Requirements and Design Documents Detailed Requirements and Design Documents Test Plans Test Documentation System Documentation Installation Guides User Manuals (SDP) WHAT HOW ER Diagram (Database) UML Diagrams (Code) CAD Drawings, etc. How to Test/ What to Test Proof that you have tested and that the software works as expected Technical Stuff (Super User/ IT dep.) How to install it How to use it (End User) (SRS) (SDD) (STP) (STD)

44 Project Documentation Documentation produced during a software Project can be divided into 2 Categories: Process Documentation These documents record the process of development and maintenance, e.g., Plans (Software Development Plan, Software Test Plan,...), Schedules (e.g., Gantt Charts), etc. Product Documentation These documents describe the product that is being developed. Can be divided into 2 sub categories: System Documentation Used by engineers developing and maintaining the system User Documentation Used by the people that is using the system

45 Documentation Categories Project Documentation Process Documentation Project Plan, Gant Chart, Meeting Documents, Requirements & Design documentation, s, Test documents, other kind of Working Documents, etc. System Documentation Technical Documentation needed in order to maintain the software, etc. Installation Guides Product Documentation User Documentation User Manual, Wikis, Online Help, etc.

46 The Software Requirements Document Software Requirements Specifications (SRS) The software requirements document is the official statement of what is required of the system developers. Should include both a definition of user requirements and a specification of the system requirements. It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it. I. Sommerville, Software Engineering: Pearson, 2010.

47 Requirements Analysis Written High-Level Requirements UML Diagrams Diagrams as Figures + Descriptions of each Use Case Document? etc. System Sketches, Flow Charts, etc. Design Sketches -both System Arcitecture and GUI mockups Diagrams as Figures + Descriptions of each SRS/SDD Document(s) CAD Drawings Diagrams as Figures + Overall Descriptions and descriptions for each table Database Diagram(s) etc. Useful when your project involves hardware

48 The Structure of the SRS Document Chapter Preface Description This should define the expected readership of the document and describe its version history, including a rationale for the creation of a new version and a summary of the changes made in each version. Introduction This should describe the need for the system. It should briefly describe the system s functions and explain how it will work with other systems. It should also describe how the system fits into the overall business or strategic objectives of the organization commissioning the software. Glossary This should define the technical terms used in the document. You should not make assumptions about the experience or expertise of the reader. User requirements definition Here, you describe the services provided for the user. The nonfunctional system requirements should also be described in this section. This description may use natural language, diagrams, or other notations that are understandable to customers. Product and process standards that must be followed should be specified. System architecture This chapter should present a high-level overview of the anticipated system architecture, showing the distribution of functions across system modules. Architectural components that are reused should be highlighted. System requirements specification This should describe the functional and nonfunctional requirements in more detail. If necessary, further detail may also be added to the nonfunctional requirements. Interfaces to other systems may be defined. System models This might include graphical system models showing the relationships between the system components and the system and its environment. Examples of possible models are object models, data-flow models, or semantic data models. System evolution This should describe the fundamental assumptions on which the system is based, and any anticipated changes due to hardware evolution, changing user needs, and so on. This section is useful for system designers as it may help them avoid design decisions that would constrain likely future changes to the system. Appendices These should provide detailed, specific information that is related to the application being developed; for example, hardware and database descriptions. Hardware requirements define the minimal and optimal configurations for the system. Database requirements define the logical organization of the data used by the system and the relationships between data. Index Several indexes to the document may be included. As well as a normal alphabetic index, there may be an index of diagrams, an index of functions, and so on. I. Sommerville, Software Engineering: Pearson, 2010.

49 Users of SRS System customers Specify the requirements and read them to check that they meet their needs. Customers specify changes to the requirements. Managers Use the requirements document to plan a bid for the system and to plan the system development process. System engineers Use the requirements to understand what system is to be developed. System test engineers Use the requirements to develop validation tests for the system. I. Sommerville, Software Engineering: Pearson, System maintenance engineers Use the requirements to understand the system and the relationships between its parts.

50 UML and Use Case Register patient Export statistics Medical receptionist View personal info. Manager Generate report View record Nurse Edit record Doctor Setup consultation Graphical models, supplemented by text annotations, are used to define the functional requirements for the system; UML use case and sequence diagrams are commonly used. We will learn more about this later!

51 Exercise SRS Create a SRS document for your system.

52 Requirements in TFS/VSTS Product Backlog & Sprint Backlog Hans-Petter Halvorsen

53 What is TFS/VSTS? Team Foundation server/visual Studio Team Services (VSTS) is an Application Lifecycle Management (ALM) system, i.e., the system takes care of all aspects in software development from planning, requirements, coding, testing, deployment and maintenance. Agile and Scrum workflow are included TFS is a Source Code Control (SCC), Bug Tracking, Project Management, and Team Collaboration platform Tightly integrated with Visual Studio as Microsoft is the vendor of both Visual Studio and VSTS Cloud based edition (Hosting Service): Visual Studio Team Services (VSTS)

54 Visual Studio Team Services (VSTS) We will use Visual Studio Team Services (VSTS) as our software collaboration platform for our software lifecycle management (SDLC). Here we will add Requirements and Design documents, add Tasks, Source Code, report Bugs, etc. VSTS is located here:

55 Team Foundation Server (TFS) vs. Visual Studio Team Services (VSTS) Visual Studio Visual Studio don't care if you use TFS or VSTS. You just hook it up using an URL. Team Foundation Server (TFS) vs. Visual Studio Team Services (VSTS) Team Foundation Server (TFS). This is software you can install on a server in your own network. You and your team can then hook up Visual Studio to that server and use TFS. You have to buy the software, buy licenses for users and use your own server. Visual Studio Team Services (VSTS) is an online version of TFS hosted by Microsoft. You don't need to install anything, you just pay a monthly fee (until 5 users is for free). VSTS is available from

56 Using TFS/VSTS to create the Backlog

57 Sprint Backlog in TFS/VSTS

58 Break items down into Tasks In the sprint backlog, add a task: Give the task a name, and estimate the work it will take:

59 Final Results:

60 Use the Taskbord to update Tasks The task board is at the heart of daily standups. Move tasks on the task board to reflect their current state.

61 Use the Taskbord to update Tasks You can assign a task to a specific person:

62 Use the Taskbord to update Tasks Update the remaining work by either using the drop-down list or typing a specific value:

63 Burndown Chart Review overall progress by opening the burndown chart for the sprint:

64 Typical Challenges O. Widder. (2013). geek&poke. Available: Stakeholders don t know what they really want. Stakeholders express requirements in their own terms. Different stakeholders may have conflicting requirements. Organisational and political factors may influence the system requirements. The requirements change during the analysis process. New stakeholders may emerge and the business environment may change. I. Sommerville, Software Engineering: Pearson, 2010.

65

66 References I. Sommerville, Software Engineering: Pearson, E. J. Braude and M. E.Bernstein, Software Engineering. Modern Approaches, 2 ed.: Wiley, F. Tsui, O. Karam, and B. Bernal, Essentials of Software Engineering, 3 ed.: Jones & Barlett Learning, Wikipedia. (2013). Software Development Process. Available: NTNU. (2013). TDT4140 Systemutvikling. Available: UiO. (2013). INF Systemutvikling. Available: O. Widder. (2013). geek&poke. Available: B. Lund. (2013). Lunch. Available: S. Adams. Dilbert. Available:

67 Hans-Petter Halvorsen, M.Sc. University College of Southeast Norway Blog: