Lecture 01 Requirements Engineering Software Engineering Software engineering

Lecture 01 Requirements Engineering

Software Engineering • Software engineering is the application of a systematic, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software. • What do we do with software?

Software-intensive System (Si. S) • Software on its own is useless – Software can only do things when it is run on a computer platform, using various devices to interact with the physical world. • Systems in which software interacts with other software, systems, devices, sensors and with people are called software-intensive systems.

Si. S and the four worlds needs Information about maintains Information about Subject World Uses Usage World System World Contracts Builds Development World

Software for real world • To make sure a software solution “correctly” solves some real-world problem, we must first fully understand define. . . – what problem needs to be solved in the real world – the context in which the problem arises

Requirements Engineering • “The descriptions of the services and constraints are the requirements for the system. the process of finding out, analyzing, documenting and checking these services and constraints is called Requirements Engineering. ” (Ian Sommerville) • The use of term ‘engineering’ implies that systematic and repeatable techniques should be used.

“Requirement” - The IEEE definition 1) A condition or capability needed by a user to solve a problem or achieve an objective. 2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.

Requirements Engineering • RE is a set of activities concerned with identifying and communicating the purpose of a softwareintensive system, and the contexts in which it will be used. (RE) The bridge • RE acts as the bridge between the real-world needs of users, customers, and other constituencies affected by a software system, and the capabilities and opportunities afforded by software-intensive technologies

The scope of RE: WHY, WHAT, WHO System-as-is System-to-be Objectives WHY a new system? satisfy problèmes, opportunités, system knowledge requirements, constraints, assumptions WHAT services? WHO will be responsible for what ?

WHY RE?

The hardest single part of building a software system • “The hardest single part of building a software system is deciding what to build. … No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later” • F. P. Brooks

Requirements - a problem • Standish Group Report highlights “incomplete requirements” as major cause of software project failures. • "in reality, change of requirements is one of the main causes of project slippage and cost overruns“ (Berkely et al) • The failure of – FAA – the Field System of the Department of Employment, UK • all highlight changing user requirements as one of the factors contributing to the failure.

Requirements - a problem • A research work done in UK, by Dr Naveed Ikram, also found that • Users are changing requirements continuously • My Research Work – Based on a Pakistan based organization: • system failed due to lack of user involvement

“No other part is more difficult to rectify later” Requirements Design Coding Unit Testing Acceptance Test Maintenance

Some types of requirements information Business requirement A high-level business objective of the organization that builds a product or of a customer who procures it. Constraint A restriction that is imposed on the choices available to the developer for the design and construction of a product. Functional requirement A description of a behavior that a system will exhibit under specific conditions. Nonfunctional requirement A description of a property or characteristic that a system must exhibit or a constraint that it must respect. Quality attribute A kind of nonfunctional requirement that describes a service or performance characteristic of a product. System requirement A top-level requirement for a product that contains multiple subsystems, which could be all software or software and hardware. User requirement A goal or task that specific classes of users must be able to perform with a system, or a desired product attribute.

Relationship Among several type of requirement information

software requirements engineering activities

Good Practices Of RE

Bad Requirements • The major consequence of requirements problems is Rework. • Rework often consumes 30 to 50 percent of your total development cost (Shull, et • al. 2002; GAO 2004). requirements errors can account for 70 to 85 percent of the rework cost (Leffingwell 1997) . 1. Insufficient user involvement 2. Inaccurate planning 3. Creeping user requirements 4. Ambiguous requirements 5. Gold plating 6. Overlooked stakeholders