1. Introduction to Software Requirement Engineering Nisa’ul Hafidhoh Teknik Informatika nisa@dsn.dinus.ac.id

2. “ The hardest single part of building a software system is deciding precisely what to build ” - F. Brooks

3. Requirements Engineering is accepted as one of the most crucial stages in software design and development as it addresses the critical problem of designing the right software for the customer.

4. Background Only 16.1% of all US software projects are developed on-schedule, on-budget and with all originally planned features 31.1% of projects are terminated before completion Survey of 350 organizations in the USA (> 8000 projects), 1/3 of projects were never completed, 1/2 succeeded only partially 1/2 of the managers interviewed identified poor requirements as a major source of problems, along with other factors such as low user involvement and unclear objectives

5. Background [2] 3800 organizations from over 17 countries in Europe, most problems are in the area of requirements specifications (50%) and requirements management (50%) Standish group report revealed that 3 of the top 10 reasons for project failure were – lack of user involvement – unstable requirements – poor project management

6. What is a Requirement? “Something that the product must do or a quality that the product must have” (Robertson99) “A description of how the system shall behave, an information about the application domain, constraints on operations, a system property etc.” (Kotonya98) “A requirement specifies how a goal should be accomplished by a proposed system” (Anton96)

7. What is a Requirement? All project begin with a statement of requirements. Requirements are descriptions of how a software product should perform. The widely cited IEEE 610.12-1990 standard defines a requirement as : – A condition or capacity needed by a user to solve a problem or archive an objective – 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 documents,

8. Requirement Requirements include not only user needs but also those arising from general organizational, government and industry standards Requirement is a collection of needs arising from the user and various other stakeholders Requirements are independent of design, showing “what” the system should do, rather than “how” it should be done

9. Requirement Classification

10. What is a Requirement? Example ¤ a constraint : the system shall include a spelling checker ¤ a required function : the system shall identify “old customers” ¤ a required quality : the print out for old customers shall be in colour

11. Requirements Engineering is the activity which transforms a fuzzy idea into a precise specification of stakeholders’ needs that shape the system to be built and therefore, defines the intended link between a system and its environment WHAT WHY Requirement Engineering

12. What is RE about? The WHY question – Why the system needs to be developed? The WHAT question – What the system shall do? Requirements definition must say – why a system is needed, based on current or foreseen conditions, – what system features will satisfy this context, (Ross77)

13. What is RE about? Mission statement, goals Requirements Specification WHY ? WHAT ? The Requirements Engineering process

14. Requirement Engineering Process Requirements engineering activities : elicitation, interpretation and structuring (analysis and documentation), negotiation, verification and validation, change management and requirements tracing.

15. Requirement Engineering Process A complex process with intertwined activities and multiple actors Elicitation Negotiation Specification Documentation Validation Client Requirements Engineer User Project manager Domain expert System Analyst facilitator

16. RE Stakeholder Typical stakeholders are product managers Various types of users and administrators from the client side Software team members from the software development side

17. The Role of Stakeholders in RE In essence, requirements engineering aims to transform potentially incomplete, inconsistent and conflicting stakeholder goals into a complete set of high quality requirements Stakeholders…”as those participants in development process together with any other individuals, groups or organizations whose actions can influence or be influence by the development and use of the system whether directly or indirectly”

18. Requirements Management Requirements Elicitation, Specification and Modeling Prioritization Requirements Dependencies and Impact Analysis Requirements Negotiation Quality Assurance

19. Requirements Elicitation, Specification and Modeling This involves understanding the needs of stakeholder, elicitation management, modeling and collecting them in a repository. This is important stage for s/w development, because the requirement tent to be incomplete and inconsitent

20. Prioritization It’s not always easy for developers to decide which requirements are important to customers. This activity assists project managers with resolving conflicts (where customers and developers collaborate on requirements prioritization), plan for stage delivers, and make necessary trade-off decisions.

21. Requirements Negotiation Req. engineering is essentially a complex communication and negotiation process involving customers, designers, project managers and maintainers. People, or stakeholders involved in the process are responsible for deciding What to Do, When to Do it, What information is needed, and What Tools need to be Used

22. Quality Assurance The objective is to ensure that high quality requirements are recorded in the specification documents. The purpose of quality assurance is to establish reasonable and realistic levels of confidence when writing and managing requirements

23. Reference Aybuke Aurum, Claes Wohlin (Eds.), “Engineering and Managing Software Requirements”, Springer