CS 5103 Software Engineering Lecture 03 Requirement Engineering

CS 5103 Software Engineering Lecture 03 Requirement Engineering

Last class Ø Ø 2 Extreme Programming Ø Small requirements Ø Simple design & implementation Ø Frequent Testing Elements in all software process models Ø Requirement (Let’s talk about it today) Ø Design Ø Implementation Ø Validation

Today’s class Ø Requirement Engineering Ø Ø 3 Concepts Ø Definition Ø Stakeholders Ø Types of requirements Process Ø Elicitation Ø Analysis Ø Specification Ø Validation

Requirements Engineering Ø First stage of software life cycle Ø Defines functionalities and constraints Ø 4 Produces a document, software requirements specification (SRS) l Customers provide a high level ideas l Software developers need a more detailed specification

Software Requirements Ø Ø Requirements are bridging the gap between the minds of customers and developers l Customers “know” what the system shall do l Developers “know” what they are going to build “Requirements are means of communication with customer and many other stakeholders” -- by Helene Wong, Ph. D thesis, 1994 5

Stakeholders Ø Ø 6 People who support, benefit from, or affected by a software project Stakeholders may include l Customers l Users l Final beneficiaries l System administrators l Supervisors

Stakeholders Example Ø Ø 7 A medical system for sharing information among medical care providers Who are the stakeholders?

Stakeholders Example Ø Ø 8 Doctors: assessing and treating patients based on the information Nurses: coordinating consultations and administer treatments Ø Medical receptionists: managing appointments Ø IT staff: installing and maintaining the system

Stakeholders Example Ø Ø Ø 9 Patients: information is recorded Medical ethics inspector: ensuring ethical guidelines being enforced Managers: obtaining management information

Types of Requirements Ø Ø 10 Functional l What is the system supposed to do l Mapping from input to output Non-functional (quality) l Performance l Resource Consumption l Usability l Reliability l Robustness l Portability l …

Measures of Non-functional Requirements Property Example Measure Performance Processed transactions/second User/event response time Resource Consumption Mbytes Number of ROM chips Usability Training time Number of help frames Reliability Mean time frame between failures Rate of failure occurrence Robustness Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Portability Percentage of target dependent statements Number of target systems 11

Types of Requirements Ø Process constraints l l l Resources l Time l Expense l People Documentation l Quantity l Content Standards l 12 Follow certain software process rules (e. g. , design review, at least 1000 test cases)

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. 13

Requirements Are Important Ø 80% of software errors are requirements errors l Here software errors are defined as errors detected after unit testing – i. e. , in integration testing, in system testing, and after the software is released l Most errors can be traced to unknown, wrong, or misunderstood requirements 14

Requirements Are Important l As time goes by, requirements errors are more expensive to fix Stage discovered Requirements 15 Relative repair cost (p. day) 0. 1 – 0. 2 Design 0. 5 Coding 1 Unit test 2 Acceptance test 5 Maintenance 20

Today’s class Ø Requirement Engineering Ø Ø 16 Concepts Ø Definition Ø Stakeholders Ø Types of requirements Process Ø Elicitation Ø Analysis Ø Specification Ø Validation

Requirements Engineering Process Elicitation Analysis Specification Validation 17

Requirements Engineering Process Determine the requirements of a system, and Ø specify what behavior is realized l Work with stakeholders to elicit the requirements l Analyze and model the requirement l Document the requirements in a software requirements specification l 18 Validate the software specification

Requirements Elicitation is to gather Ø l Functions that the system should perform l Non-functional requirements that the system should exhibit Elicitation is critical but difficult Ø l Customers are not good at describing what they want l Software engineers are not good at understanding what customers want l Customers and software engineers speak different languages 19

Elicitation Approaches Ø Brainstorming Ø Interviewing Ø Ethnography Ø Strawman/Prototype Ø Testable User Story 20

Brainstorm Gather stakeholders, collect ideas from them and Ø prune ideas Organization Tips: Ø 21 Ø Keep the number of participants “reasonable” Ø Invite the most creative people to multiple sessions

Brainstorm - the Storm Purpose Ø Ø Generate as many ideas as possible Ø Quantity, not quality, is goal at this stage Common Rules Ø 22 Ø No criticism or debate Ø Write down all ideas where all can see Ø No self-censor or wondering if an idea is practical Ø Original list does not get circulated outside of the meeting

Brainstorm – the Calm Purpose Ø Ø Review, consolidate, combine, clarify, and expand Ø Rank the list by priority somehow; choose a winner Common Rules Ø Ø Go over the list and explain ideas more carefully Ø Categorize into “maybe” and “no” by pre-agreed consensus method (e. g. , voting, priority points) Ø Be careful about time: meetings should have a fixed time frame (90 -120 minutes) 23

Brainstorm: Pros & Cons? Ø Ø Ø Pros Ø No Preliminary Knowledge Preparation Ø Comprehensive gathering of ideas, solve conflicts earlier Cons Ø No clear mission, costly for gathering, may take a long time Ø People from different field may feel difficult to interact Applicability? (Android shopping vs. Banking system) Ø Good: Startup software, General topic, e. g. personal shopping software Ø Not good: Domain experts/systems exist, limited time, e. g. , banking system

Interviews Ø Formal or informal interviews with stakeholders Ø Types of interview Ø § Closed interviews: based on pre-determined list of questions § Open interviews: issues are explored with stakeholders. Effective interviewing § § Prompt the interviewee to get discussions going using a requirements proposal Be open-minded, avoid pre-conceived ideas 25

Interviews in practice Ø Mostly used approach for requirement elicitation: in almost every project Ø Normally a mix of closed and open-ended interviewing Ø Surveys are written closed interviews Ø Fewer flexibility Ø Better coverage

Interviews: Pros & Cons Ø Ø Pros Ø Simple to apply in practice Ø Usually can get some progress Cons Ø Ø Interviewee may ignore details because they are too familiar with them Interviewee may have too little knowledge in computer science to express their ideas effectively

Talk based requirement gathering Ø Ø Ø Terminology Problem Sometimes people fails to articulate what they want Ø Too familiar to come up with Ø Fail to go to the details Solution: Practice based requirement gathering

Ethnography ² ² ² A social scientist 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. 29

Ethnography for Requirement Ø Ø Discover requirements by observing the way that people actually work This include the interaction and collaboration between people doing their work Ø Ø Talks, emails, meetings, … Gathering of real data generated in the actual work Ø reports Ø filled forms Ø emails, … 30

Ethnography: Pros & Cons? Ø Pros Ø Ø Ø Require little preliminary knowledge Cons Ø May take a long time to finish an effective observation Ø May have legal or privacy issues Ø Ø Reveal requirements, avoid problems caused by imprecision in oral/written expression Can only observe what is happening at present, but people’s behaviour may change with the new software Frequently used in practice when there is an existing system in use 31

Strawman/Prototype Ø Prototype: Write a prototype software for requirements Ø 32 Strawmen: something to convey ideas without coding Ø GUI Ø web pages Ø flow chart of UIs

Straw man: flow chart 33

Strawman/Prototype: Pros & Cons Ø Ø Ø 34 Pros Ø Can go to details Ø Easy to link requirements to design/implementation Ø Most accurate Cons Ø High cost in preparation Ø Require preliminary knowledge Ø Pre-assumptions may limit the scope of the software Frequently used in later iterations in iterative software process

Combination of different approaches Ø Brainstorm + interview Ø Ø Interview + strawman/prototype Ø Ø Asking people after observing their work Prototype + ethnography Ø 35 Talk to interviewee with a strawman/prototype Interview + ethnography Ø Ø Raise some questions, then ask more people Observe how people work on a prototype

Requirements Engineering Process Elicitation Analysis Specification Validation 36

Requirements Analysis Requirements analysts have to understand the Ø system from each stakeholder's point of view l Stakeholders have different views of the system Ø Requirements analysts resolve conflicting views Ø Requirements analysts prioritize requirements 37 l Essential requirements l Desirable requirements l Optional requirements

Requirements Analysis Goal Ø Ø Categorization, negotiation, and decision: Ø Ø Determine the scope of the software Ø Few established fixed approaches Ø Large amount of mental work based on domain knowledge Project manager/customer representative often plays the key role 38

Today’s class Ø Requirement Engineering Ø Ø 39 Concepts Ø Definition Ø Stakeholders Ø Types of requirements Process Ø Elicitation Ø Analysis Ø Specification Ø Validation

Next Class Ø Requirement Specification & Validation Ø Use case diagram (A good way to specify requirements) 40

Thanks! 41