CS 5103 Software Engineering Lecture 03 Requirement Engineering
- Slides: 41
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
- Requirement adalah
- User requirement
- Requirement analysis model in software engineering
- Requirement analysis in software engineering notes
- Requirement analysis steps in software engineering
- Requirement analysis plan
- 01:640:244 lecture notes - lecture 15: plat, idah, farad
- Dfd symbols
- Software requirement specification for banking system
- Software requirement and design
- Software requirement and design
- Software processes
- Characteristics of software requirements
- Chapter3
- Srs in software engineering
- Software requirement analysis and specification
- Pspec in software engineering
- Requirements engineering
- Seven distinct tasks to requirements engineering
- Numerical assignment
- Inception in requirement engineering
- Requirement engineering adalah
- Pengertian rekayasa kebutuhan
- Requirement engineering
- Elaboration in requirement engineering
- Requirement engineering template
- Software maintenance in software engineering ppt
- Frank maurer
- What is software metrics in software engineering
- Software crisis in software engineering
- Halstead software metrics example
- Real time software design in software engineering
- Design principles in software engineering
- System architecture example
- Forward engineering in software engineering
- Project management notes
- Lecture presentation software
- Financial engineering notes
- Foundation engineering lecture notes
- Professional ethics in engineering notes
- Working capital requirement
- Reserve requirement ratio