ELICITATION & ANALYSIS REQUIREMENTS ELICITATION & ANALYSIS 9/17/2019

Outline Objectives and basic concepts Requirement engineering process Requirement engineering metrics Challenges 9/17/2019

Aim of Requirement Engineering To determine the client’s needs NOT what the client’s wants 9/17/2019

Requirements elicitation (capture) The process of discovering the client’s requirements Requirements analysis (understand and refine) Once the initial set of requirements has been drawn up, the process of refining and extending them 9/17/2019

Elicitation & analysis flowchart 9/17/2019

Gain an understanding of the application domain The specific environment in which the target product is to operate Build a business model Model the client’s business processes Concept exploration (determine the client’s) initial requirements constrains (deadline, reliability, cost) Iterate the above steps Examples: banking, automobile, manufacturing, or nuclear physics, education 9/17/2019

Understanding the Domain (Before contact your client) Every member of the development team must become fully familiar with the application domain Correct terminology is essential Construct a glossary A list of technical words used in the domain, and their meanings 9/17/2019

Building Business Model (contact your client) A business model is a description of the business processes of an organization The purpose is for developers to further understand the clients business so they can better advise clients regarding to what they need 9/17/2019

A simple business processes of a bank Accepting deposits and account withdraw Loaning money to clients Making investments 9/17/2019

Sources of requirements Customers Users Administrators Maintenance staff Partners Domain experts Industry analysts Information about competitors Good requirements start with good sources. Finding those high-quality sources is an important task and, fortunately, one that takes few resources. The primary sources of requirements are the Stakeholders, so begin by identifying them from among these candidates: Customers Users Administrators Maintenance staff Partners Ask each stakeholder to identify other stakeholders. By “peeling the onion” in this manner you can quickly identify all stakeholders so that you don't miss important perspectives and associated requirements.  This will help you identify and resolve conflicting requirements as early as possible. These are other possible sources of ideas for requirements: Domain experts Industry analysts Information about competitors The last item often includes information about the current system that competitors are using to solve the business problem. 9/17/2019

Techniques Brainstorming Interviewing A questionnaire Examination of business forms Direct observation Prototyping Requirement gathering workshop 9/17/2019

The six key question types What? Why? When? How? Where? Who? “I keep six honest serving men (They taught me all I knew); Their names are What and Why and When And How and Where and Who.” ...Rudyard Kipling. Ask the right questions! 9/17/2019

How requirements questions How will you use this feature? Is this feature a process and, if so, what are the steps? Or, what questions can I ask to ascertain the steps? How might we meet this business need? How might we think about this feature a bit differently? How will we know this is complete? 9/17/2019

Where requirements questions? Where does the process start? Where would the user access this feature? Where would the user be located physically when using this feature? Where would the results be visible? 9/17/2019

When requirements questions? When will this feature be used? When do you need to know about…? When will the feature fail? When will we be ready to start? 9/17/2019

Who requirements questions? Who will use this feature? Who will deliver the inputs for the feature? Who will receive the outputs of the feature? Who will learn about the results of someone using this feature? Who can I ask to learn more about this? 9/17/2019

What requirements questions? What do I know about this feature? Or, what assumptions am I making about this feature that I need to confirm? What does this feature need to do? What is the end result of doing this? What are the pieces of this feature? What needs to happen next? What must happen before? What if….? Think of all the alternative scenarios and ask questions about what should happen if those scenarios are true. What needs to be tracked? 9/17/2019

Why requirements questions? Why questions are great wrap-up questions as they help confirm that the requirements you just elicited map back to a need you identified when you scoped the project. Is there any other way to accomplish this? Does this feature meet the business need and solve the problem we’re trying to solve? 9/17/2019

Initial Requirements (contact your client) The initial requirements are based on the initial business model Vague, unreasonable, contradictory, impossible to achieve Then they are refined The requirements are dynamic 9/17/2019

Two categories of requirements A functional requirement specifies an action that the software product must be able to perform A nonfunctional requirement specifies properties of the software product itself Platform constraints Response times Reliability Functional requirements are handled as part of the requirements and analysis Some nonfunctional requirements have to wait until the design workflow 9/17/2019

Develop SMART requirements Make sure the requirement is: Specific –clearly states what is required Measurable – to confirm when it has been met Achievable – can be done, eg. technically possible Realistic – is reasonable, eg. cost is not prohibitive Timely – achievable within an acceptable timeframe. 9/17/2019

SMART Definition – Specific: Specific requirements are precise and: Are not open to interpretation; and Avoid absolutes (ex. – “all”, “never”, “always”). 9/17/2019

SMART Definition – Specific: The document will contain all customer information: Which document? What customer information? What format(s)? The Declaration document shall contain this customer information in a text block in the top right corner of the first page: Customer Name, Phone, Email 9/17/2019

SMART Definition – Measurable: Measurable requirements can be verified as complete and: Avoid undefined time periods / quantities; and, Avoid non-fact based measurements such as “best” or “optimal”. 9/17/2019

SMART Definition – Measurable The application shall function quickly for end users: How quickly (seconds, minutes, hours)? Which application features are included? Which users are affected – guests, administrators, everyone? The application shall have response times of 4.00 seconds or less for all features, and for all user roles, during business hours of 9 AM – 5 PM ET, Mondays – Fridays. 9/17/2019

SMART Definition – Attainable Attainable requirements are able to be achieved given the existing environment and are: Appropriate for project / limitations; and, Realistic to achieve within project parameters. 9/17/2019

SMART Definition – Attainable The monthly cycle will be run on the last Friday of the month, between 7 PM and 8 PM ET: Has this been verified to be possible? What if the cycle runs longer than 1 hour? The monthly cycle will be run on the last Saturday of the month, starting at 7 AM and completing by 7 PM ET. 9/17/2019

SMART Definition – Realistic: Specific requirements are relevant and: Are appropriate in context with other requirements; and, Consider other related project constraints. 9/17/2019

SMART Definition – Realistic: The new website will generate over 1,000,000 hits within its first 12 hours of implementation: Is this likely / necessary to occur? Is there a better way to measure this outcome? The new website shall be ranked within the first results page on three (3) major search engines (Google, Bing and Yahoo) within its first 12 hours of implementation. 9/17/2019

SMART Definition – Time-Bound: Time-Bound requirements are timely and: Clarify how quickly a requirement needs to be finished, executed or implemented. Avoid vague time references such as “fast”, “quick” or “soon”. 9/17/2019

SMART Definition – Time-Bound: System availability will be achieved soon after the cycle is completed: How soon (seconds, minutes, hours)? What if the cycle is late? System availability shall be achieved after cycle completion and by no later than 6 AM ET on Mondays – Fridays. 9/17/2019

Software Metrics 9/17/2019

9/17/2019

Metrics for requirement engineering Requirements changing frequency during the elicitation and analysis phase Management use this to determine the rate of converging to the real requirements # of requirement changes during the rest of the development process Management use this to evaluate the techniques used during the elicitation and analysis phase 9/17/2019

Challenges 9/17/2019

9/17/2019

“ I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant.” S. I. Hayakawa (1906-1992), U.S. senator from California 9/17/2019

George Romney (1907-1995), U.S. presidential candidate “I didn’t say that I didn’t say it. I said that I didn’t say I said it. I want to make that very clear.” 9/17/2019

Challenges in requirement engineering What system analysts say is not what the client should be saying: Clients don’t know what they need Client can’t convey what they need Client don’t appreciate what is really going on It is easy to misunderstand what the client says. Ambiguous of language Complexity of software 9/17/2019

Object-oriented & classical path 9/17/2019

Gain Domain Knowledge Build Business Model Use Cases Initial Requirement Refine Use Case & Requirement Requirement Analysis Build Rapid Prototype Experiment with Rapid Prototype 9/17/2019

Use Case Model Models an interaction between the software and users of software (actors) An actor is a member of the world outside the software product An actor is frequently a user of the software product A user of the system can play more than one role Conversely, one actor can be a participant in multiple use cases 9/17/2019

An Example of Use Case Diagram 9/17/2019

Use Case Description for Check Out Brief description: The Check Out Book use case enables a borrower to check out a book with the aid of a librarian. Step-by-step description: 0. The borrower hands the book and his or her card to the librarian. 1. The librarian enters C at the computer terminal, and then scans the bar code on the book and on the borrower’s card. 2. If the book has a hold on it for another borrower, the librarian does not allow the borrower to check that book out. 3. If the book has a hold on it for that borrower, the system clears the hold and then updates the relevant book data. 4. If there was no hold on the book, the system updates the relevant book data. Unless there was a hold on the book for another borrower, the librarian stamps the book and hands it to the borrower. The librarian returns the card to the borrower. 9/17/2019

CASE Tools Graphical tools for UML diagrams Object-oriented CASE tools To make it easy to change UML diagrams The documentation is stored in the tool and therefore is always available Object-oriented CASE tools Rational Rose (http://www.ibm.com) Together ArgoUML (open source) (http://argouml.tigris.org/) 9/17/2019