Software Requirements and Specification - Software Engineering | CS 5103, Study notes of Software Engineering

Download Software Requirements and Specification - Software Engineering | CS 5103 and more Study notes Software Engineering in PDF only on Docsity! 1 CS5103 Software Engineering Lecture 02 Software Requirements and Specification UTSA CS51032 Requirements Engineering Requirements engineering is usually the first stage of software life cycle Requirements engineering is the process of understanding and defining functionalities and constraints of proposed systems Requirements engineer produces a document, software requirements specification (SRS) – Customers need a high level specification, i.e., user requirements – Software designers and developers need a more detailed specification, i.e., software specification UTSA CS51033 Software Requirements Requirements are desired behavior – Customers “know” what the system shall do – Software engineers “know” what to build “Requirements are means of communication with customer and many other stakeholders” -- by Helene Wong, PhD thesis, 1994 Requirements deal with – Objects – States – Functions UTSA CS51034 Software Requirements Requirements analysts or system analysts determine requirements Stakeholders contribute to requirements of systems – Clients – Customers – End-users – Software engineers – Domain experts – Lawyers or auditors – Market researchers 2 UTSA CS51035 Types of Requirements Functional – What is the system supposed to do – Mapping from input to output Non-functional (quality) – Usability – Performance – Security – Reliability – Maintainability – Portability UTSA CS51036 Types of Requirements Process constraints – Resources – Documentation – Standards Design constraints – Physical environment – Interface – Users UTSA CS51037 Requirements Are Important 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, including all interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. -- by Frederick Brooks, “No silver bullet: essence and accidents of software engineering”, 1986. UTSA CS51038 Requirements Are Important 80% of all software errors are requirements errors – These are software errors detected after unit testing – i.e., in integration testing, in system testing, and after the software is released – Most errors can be traced to unknown, wrong, or misunderstood requirements 5 UTSA CS510317 Requirements Elicitation Requirements analysts have to understand the problem from each stakeholder's point of view – Stakeholders have different views of the system Requirements analysts resolve conflicting views – Essential requirements – Desirable requirements – Optional requirements UTSA CS510318 Elicitation Techniques Understand problems For existing system – Review documentation – Observe current system – Questionnaires and Interviews – Apprenticeship For new systems - brainstorming UTSA CS510319 Analyze Existing System What is used, what isn't, what's missing What works well, what doesn't How the system is used, how it was intended to be used, what new ways we want it to be used Risks – Users might not be happy with too much change from the old system – Might miss real usage patterns – Might miss obvious possible improvements UTSA CS510320 Analyze Existing System - Review Review all available documentation – For an automated system, review its requirements specifications and user manuals, as well as development documentation, internal memos, change histories, etc. – For a manual system, review any documented procedures that the workers must follow Gain knowledge of the system before imposing upon other people's time, before bothering the stakeholders 6 UTSA CS510321 Analyze Existing System - Observation Identify what aspects to keep and to understand the system you are about to change The system contains a lot of useful functionality that should be included in any future system Documentation rarely describes a system completely and not up to date The current operation of the system may differ significantly from what is described UTSA CS510322 Analyze Existing System - Interview Questionnaires are useful when information has to be gathered from a large number of people The answers to questions need to be compared or corroborated. Ask problem-oriented questions during interview Interview groups of people together to get synergy UTSA CS510323 Analyze Existing System - Apprentice The requirements analyst is the apprentice and the user is the master craftsman. The user can – Describe the task precisely – Explain why the task is done this way – List the exceptions that can occur UTSA CS510324 Brainstorm Brainstorm is used to gather ideas from every stakeholder and prune ideas When you have no idea, or too many ideas, sit down and thrash it out, but with some ground rules Most useful early on, when terrain is uncertain, or when you have little experience, or when novelty is important 7 UTSA CS510325 Brainstorm Keep the tone informal and non-judgmental Encourage creativity Keep the number of participants “reasonable”, if too many, consider a “playoff”-type filtering Invite back most creative to multiple sessions UTSA CS510326 Brainstorm - the Storm Generate as many ideas as possible Quantity, not quality, is goal at this stage No criticism or debate is permitted Write down all ideas where all can see Participants should NOT self-censor or spend too much time wondering if an idea is practical Original list does not get circulated outside of the meeting UTSA CS510327 Brainstorm – the Calm Go over the list and explain ideas more carefully Categorize into “maybe” and “no” by pre-agreed consensus method Be careful about time Meetings tend to lose focus after 90 to 120 minutes Review, consolidate, combine, clarify, and expand Rank the list by priority somehow; choose a winner UTSA CS510328 Brainstorm – Pruning Vote with threshold – Each person votes up to n times – Keep those ideas with more than m votes – Have multiple rounds thereof with smaller n and m Vote with campaign speeches – Each person votes up to j < n times – Keep those ideas with at least one vote – Have multiple rounds thereof with smaller j 10 UTSA CS510337 Specification Verification Verify the specification against requirements – Conforms to the requirement definition – Build the system right Verification can be done with techniques – Simulation – Consistency checks – Completeness checks – Formal verification: model checking or mathematical reasoning UTSA CS510338 Software Requirements Specifications Introduction Overall description Specific requirements Supporting information UTSA CS510339 Software Requirements Specification Section 0 – Table of Contents Essential for tracing through use cases, classes, state diagrams – Table of Figures Essential for finding each diagram UTSA CS510340 Software Requirements Specification Section 1 Introduction 1.1 Purpose of the SRS e.g., the intended audience 1.2 Scope 1.3 Acronyms, abbreviations, notational conventions 1.4 Overview e.g., the structure of the rest of the SRS 1.5 References Can be put at the end of the document 11 UTSA CS510341 Software Requirements Specification Section 2 General description 2.1 Product perspective – the environment Any hardware and software components that interact with the system Overview of the interfaces to other component A block diagram would be nice UTSA CS510342 Software Requirements Specification Section 2 General description 2.2 Product functions Overview of the system’s main functions No detail description At the level of use case names 2.3 User characteristics Assumptions about the user UTSA CS510343 Software Requirements Specification Section 2 General description 2.4 General constraints e.g., laws, hardware limitations Any sources of constraints on requirements or design 2.5 Assumptions and Dependencies Assumptions about the environment Any environmental conditions that could cause the system to fail UTSA CS510344 Software Requirements Specification Section 3 Specific requirements 3.1 Functional requirements 3.1.1 Use case diagrams 3.1.2 Class diagrams 3.1.3 State diagrams 3.1.4 Sequence diagrams In sections 3.1.x, give English introduction to each diagram to help the reader understand each diagram. In section 3.1.1, number each use case for future reference 12 UTSA CS510345 Software Requirements Specification Section 3 Specific requirements 3.1 Functional requirements 3.1.5 Data dictionary in tabular format Classes: purpose Attributes: purpose, range of values Operations: purpose, parameters, pre/post conditions Events: purpose, source, destination, parameters UTSA CS510346 Software Requirements Specification Section 3 Specific requirements 3.2 User interface requirements Screen shots Purpose of each button, menu options, etc. List of input/output events How to navigate among windows UTSA CS510347 Software Requirements Specification Section 3 Specific requirements 3.3 Non-functional requirements Reliability Portability Security … UTSA CS510348 Software Requirements Specification Section 4 Functional requirements table – Requirement number – Name – Description – Related requirements’ numbers and source – Related use cases’ numbers