Requirement Engineering

Requirement Engineering Lecture 1 Saria Safdar

Introduction • Question of the day • Can you walk on the water? • Think and discuss at the end of the lecture • This week • Today • Aims & Intro to course • Syllabus • Reading • What are requirements?

Introduction • What should we learn in this course about RE • The role of requirements in software development • The system development view, the user view, and their intersection • How to collect report and manage requirements • What is the state of the art of RE research • User’s and developer’s point of view

Background • Development of failed software since 60s: • Systems being delivered late over budget • They don’t really do what user wanted to • Never been used to their full effectiveness by people • Reason ? • No single reason / single solution to the problem • Major contributory factor – “ Difficulties with system requirement” • System requirement • What the system is required to do and the circumstances under which it is required to operate • A requirement is a necessary attribute in a system

Requirement • Something required, something wanted or needed • Webster’s dictionary • There is a huge difference between wanted and needed and it should be kept in mind all the time • Sources of Requirements • Stakeholders • People affected in some way by the system • Documents • Existing system • Domain/business area

What are requirements? • A statement of a system service or constraint • Defined early as specification of • what should be implemented • Description of how the system should behave, domain information, constraints on system operation • So the requirement might describe • A user level facility - spell checker and correction • A very general system property - personal information disclosure • A specific constraint on system - sensor must be polled 10 times a second • How to carry out some computation - some formula

Why are Requirements important? • They provides the basis for all the development work that follows • Once the requirements are set, developers initiate other technical work: • System design, development, testing, implementation and operation

Requirements Engineering • The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. • The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process.

Requirement Classification • Requirements are commonly classified as (IEEE std 830, 1998): (Need to be discussed in next class) • Functional: • A requirement that specifies an action that a system MUST be able to perform, without considering physical constraints • A requirement that specifies input/output behavior of the system • Non-Functional: • A requirement that specifies system PROPERTIES, such as environmental and implementation constraints, performance, dependencies, maintainability, extensibility and reliability. • Often classified as: • Performance Requirements • External interface requirements • Design constraints • Quality attributes

Requirements problems • Many system engineering problem stem from problems with the system requirement • Common problems are: • The requirements don’t reflect the real needs of the customer for the system. • Requirements are inconsistent and/or incomplete. • The system shall allow users to search for an item by title, author, or by ISBN? – is the requirement incomplete • It is expensive to make changes to requirements after they have been agreed. • There are misunderstandings between customers, those developing the system requirements and software engineers developing or maintaining the system.

Identifying Problem • Whichproblem needs to be solved? • Whereis the problem? • Whoseproblem is it? • Whydoes it need solving? • Howmight a software system help? • Whendoes it need solving? • Whatmight prevent us from solving it? Boundaries Problem Domain Stakeholder Stakeholders Goal Scenarios Development Constraints Feasibility

Cont… • Significant Difference – Asking & Accepting • Often huge difference – stated & real requirement • Stated Requirement • Those provided by a customer at the beginning of software development effort • Real Requirement • Those that reflect the verified needs of user for a particular system • Identification is interactive and Iterative requirement process • Analysis of stated requirement helps to determine • The refine real needs and expectations of the user from the delivered system

So many different types of requirement • Not possible to • Describe a standard way of writing requirement • Define best way to specify requirement • It depends on: • Who is writing the requirement • Who is likely to read the requirement • General practices of the developing organization • The application domain of the system

Requirements engineering processes • The processes used for RE vary widely depending on: • The application domain, • The people involved and • The organisation developing the requirements. • However, there are a number of generic activities common to all processes • Requirements elicitation; • Requirements analysis; • Requirements validation; • Requirements management.

Processes • A process is an organized set of activities which transforms inputs to outputs • Process descriptions encapsulate knowledge and allow it to be reused • Examples of process descriptions • Instruction manual for a dishwasher • Cookery book • Procedures manual for a bank • Quality manual for software development

RE Process - inputs and outputs

Elicitation and analysis • Sometimes called requirements elicitation or requirements discovery. • Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints. • May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders.

Requirement Elicitation (Techniques) • Requirement Elicitation - requirements discovery • Fact Gathering Techniques • Interviews • Questionnaires • Analyzing documents • Observation – ethnography (A social scientists spends a considerable time observing and analysing how people actually work. • People do not have to explain or articulate their work. • Social and organisational factors of importance may be observed. • )

Types Software engineers responsible for system development System end-users who will use the system after it has been delivered Managers of system end-users who are responsible for their work External regulators who check that the system meets its legal requirements Domain experts who give essential background information about the system application domain Stakeholders

ATM Stakeholders • Bank customers • Representatives of other banks • Bank managers • Counter staff • Database administrators • Security managers • Marketing department • Hardware and software maintenance engineers • Banking regulators

Interviewing • In formal or informal interviewing, the RE team puts questions to stakeholders about the system that they use and the system to be developed. • There are two types of interview • Closed interviews where a pre-defined set of questions are answered. • Open interviews where there is no pre-defined agenda and a range of issues are explored with stakeholders.

Interviews in practice • Normally a mix of closed and open-ended interviewing. • Interviews are good for getting an overall understanding of what stakeholders do and how they might interact with the system. • Interviews are not good for understanding domain requirements • Requirements engineers cannot understand specific domain terminology;

Effective interviewers • Interviewers should be: • open-minded, • willing to listen to stakeholders and • should not have pre-conceived ideas about the requirements. • They should prompt the interviewee with a question or a proposal and should not simply expect them to respond to a question such as ‘what do you want’.

Effective interviewers • Prepare yourself as well as the user. Send them warm-up materials. • Depending on their role and availability, meet in a neutral place. • Meeting room. • Reduces distractions for both parties. No email or ringing phones. Turn off your phone • Bring: • tape recorder • legal pad for both of you • colored pens • business cards • Role play if the user’s explanation is unclear. • Users cannot express the procedures they follow • The management says one thing, operational reality is completely different.

Storyboarding • Passive storyboards – • sketches, pictures, screenshots, Powerpoint presentations, or sample outputs. Use stick figures. • Active storyboards – • automated slide presentation or movie describing the way the system behaves. • Interactive storyboards – • require participation by the user. Throw away code. Sample interface or reporting outputs; very close to a throwaway prototype.

Requirements Analysis • The aim of requirements analysis • “To discover problems with the system requirements, especially incompleteness and inconsistencies” • Analysts read the requirements, highlight problems, and discuss them in requirements review meetings • This is a time-consuming and expensive activity

Requirements Analysis (checks) • Necessity checking • The need for the requirement is analyzed. • In some cases, requirements may be proposed which don’t contribute to the business goals of the organization or to the specific problem to be addressed by the system. • Consistency and completeness checking • The requirements are cross-checked for consistency and completeness. • Consistency means that no requirements should be contradictory • Completeness means that no services or constraints which are needed have been missed out. • Feasibility checking • The requirements are checked to ensure that: • They are feasible in the context of the budget and schedule available for the system development.

Problems of Requirements Analysis • 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 change.

Requirements Negotiation • Disagreements about requirements are inevitable when a system has many stakeholders. • Conflicts are not ‘failures’ but reflect different stakeholder needs and priorities • Requirements negotiation is the process of discussing requirements conflicts and reaching a compromise that all stakeholders can agree to

Requirements Negotiation Stages • Requirements discussion • Requirements which have been highlighted as problematical are discussed and the stakeholders involved present their views about the requirements. • Requirements prioritization • Disputed requirements are prioritized to identify critical requirements and to help the decision making process. • Requirements agreement • Solutions to the requirements problems are identified and a compromise set of requirements are agreed. • Generally, this will involve making changes to some of the requirements.

Requirements Management • The process of managing change to the requirements for a system • The principal concerns of requirements management are: • Managing changes to agreed requirements • Managing the relationships between requirements • Managing the dependencies between the requirements document and other documents produced in the systems engineering process

Requirements Management VS Requirement Traceability • Req Management Vs Req Traceability • Requirements cannot be managed effectively without requirements traceability • A requirement is traceable if • you can discover who suggested the requirement, • why the requirement exists, • what requirements are related to it and • how that requirement relates to other information such as systems designs, implementations and user documentation

RE process problems • Lack of stakeholder involvement • Business needs not considered • Lack of requirements management • Lack of defined responsibilities • Stakeholder communication problems • Over-long schedules and poor quality requirements documents

RE process problems • Personality and status of stakeholders • May be from different department and may not give quality time to RE • The personal goals of individuals within an organization • May consider their own interest, may not talk about the goal of other • The degree of political influence of stakeholders within an organization • Seniors Vs junior viewpoint • Political interest and pressure group

Walking on water and developing software from a specification are easy • if they are frozen

Requirement Engineering