Software Requirements Engineering What Why Who When and

Software Requirements Engineering: What, Why, Who, When, and How Lecture 2

What is a requirement? • Definition may range from: – A high-level abstract statement of a service or of a system constraint, to – A detailed functional specification. 2

Software Requirements • A complete description of: – what the software system will do without describing how it will do it is represented by the software requirements • Software requirements are complete specification of the desired external behavior of the software system to be built – They also represent External behavior of the system 3

• If software requirements are not right, companies will not end up with the software they need. This Paper discusses: – What: The various levels and types of requirements that need to be defined – Why: The benefits of having the right software requirements – Who: The stakeholders of the software requirements and getting them involved in the process – When: Requirements activities throughout the software development life cycle – How: Techniques for eliciting, analyzing, specifying, and validating software requirements 4

WHAT • Requirements – The requirements define the “what” of a software product: • What the software must do – Functional Requirements – The capabilities of the software • What the software must be – Non- Functional Requirements – The characteristics, properties, or qualities of the software • What limitations there are on the choices – When implementing the software. 5

Functional Requirements • • • • The services the system should. Example provide. Baggage Handling System. How willsystem react shall to inputs. – 1. 1 it. The handle up to 20 bags per Need to explicitly state what the system minute should not do. – 1. 4 When the system is in idle mode, the • Can be high-level general (user conveyor belt shalland not move requirements) or detailed, expressing – 1. 8 If main power fails, the system shall shut inputs, outputs, exceptions, etc. (system down in an orderly fashion within 5 seconds requirements). – 1. 41 forms If the conveyor belt motor fails, • Many of representation fromthe NL, visual models, to formal methods. system shall shut the input feed mechanism within 3 seconds 6

Non-functional Requirements • • Baggage Handling System. Example Requirement imposed by the environment • Product requirements in which the system is to exist. • Performance (e. g. number of bags per minute) • This includes timing constraints, quality • Space (e. g. physical size of system, amount of memory, power consumption) – Reliability (MTBF, MTFF) properties, standard adherence, – Portability (e. g. can it be used with other hardware? ) –programming Usability (amount of training required) languages to be used, etc. – Efficiency • Organizational requirements – Delivery (e. g. date of delivery, fully operational, training sessions, updates) – Implementation (e. g. full opertaional) – Standards (if there are industry standards for baggage handling systems) • External requirements – Interoperability (e. g. with other equipment, communications standards, etc. ) – Ethical (e. g. security clearance for REs, professional certification) – Legislative • Safety (OSHA) 7

Why • Eliciting, analyzing, and writing good requirements are the most difficult parts of software engineering. – “If you don’t get the requirements right, it doesn’t matter how well you do anything else. ” – One can end up doing a perfect job of building the wrong product. – Karl Wiegers Why 8

Why • Non serious Requirements surface: – many issues that can have a negative impact on software development projects and products if requirements are not dealt properly: • These issues include: – Incomplete requirements – Requirement errors – Gold plating Why 9

Why Requirements Incomplete Requirements Why Consequences building a software product that does not meet all of the customer and user’s needs 10

Why Requirements Consequences 70 percent to 85 percent of the rework costs on a software project (Wiegers) Requirements Errors Why • One requirements defect if found during the requirements phase and it costs one unit to fix, the cost of fixing that same defect will typically increase as it is found later and later in the life cycle 11

Why Requirements Gold plating Consequences when a developer adds functionality to the software that was not in the requirements specification but that they believe “the user will just love” without putting that functionality through the requirements engineering process. • Why Users may or may not want the new functionality • If they don’t, the cost of developing it is a waste 12

Who • Stakeholders are individuals who affect or are affected by the software product and therefore have some level of influence over the requirements for that software product. 13

Stakeholders Type Role • Can be divided into two major groups. • There are the customers who request, Acquirer of purchase, and/or pay for the software product in order to meet their business product objectives. • The users/ end-users, who actually use the product directly or use the product indirectly by receiving reports, outputs, or other information generated by the product. Who 14

Stakeholders Type Role • include individuals and teams that Suppliers of are part of the organization that the software develops the software product or are product part of the organizations that distribute the software product or are involved in other product delivery methods (for example, outsourcing). Who 15

Stakeholders Type Role • The requirements analyst/business analyst/ system analyst, is responsible for : • eliciting the requirements from the Suppliers of customers, users, and other the software stakeholders, product • analyzing the requirements, writing the requirements • specification, and communicating the requirements to development and other stakeholders. Who 16

Stakeholders Type Role • The designers are responsible for: • Translating the requirements into the software’s architectural and detailed designs that specify how the software Suppliers of will be implemented the software • The developers are responsible for : product • implementing the designs by creating • Who the software products. The testers use the requirements as a basis for creating test cases 17

Other Stakeholders • Examples of other requirements stakeholders include: Identifying the stakeholders and getting them – Legal or contract management involved in the requirements – Manufacturing or product engineering release process brings different perspectives to the management table can in a more complete set of – that Sales andaid marketing requirements early in the software – Upper management development life cycle – Government or regulator agencies – Society at large Who 18

Stakeholders • Identifying and considering the needs of all of the different stakeholders can help prevent software product requirements from being overlooked. Who 19

When • Requirements development activities includes: – identifying, capturing, and agreeing upon the requirements – The definition and integration of the business requirements, the user requirements, and software product level requirements • Majority of the activities occur early and elaboration can progress later. • Requirements management activities involved in: – Requesting changes to the base-lined requirements, – Approving or disapproving those changes, and implementing the approved changes. • software product is validated against its requirements during the testing 20

How • Software requirements engineering is a disciplined, process-oriented approach to the definition, Change problem, Industry Reportsrequests, standards, from existing laws, documentation, and maintenance of software Lessons learned and/or systems regulations requirements throughout the software development stakeholders’ needs, assumptions, lifemelded cycle. etc are and refined • Requirements development is an iterative process. Requirements documentation, SRS, Use-case, RS etcnot expect to go through the steps in a • Onesystem should Completeness, consistency, • one-shot, linear fashion modifiability, Unambiguous, traceable, testable etc 21

Requirements Engineering • RE the Process: – Enables developers to systematically determine the requirements for a software product – Establish the services (that the customer requires from a system) and the constraints (under which it operates and is developed). • The requirements are the descriptions of: – The system services and – Constraints that are generated during the requirements engineering process. 22

Requirements Engineering • • RE contains: – A set of activities for discovering, analyzing, documenting, validation and maintaining a set of requirements for a system (Sommerville) – The processes involved in developing system requirements What is a requirements engineering process? – The structured set of activities involved in developing system requirements – RE – two main groups of activities • Requirements development – Activities related to discovering, analyzing, documenting and validating requirements • Requirement Management – Activities related to maintenance, identification, traceability and change management of requirement 23