Embed Size (px)
Citation preview
MGMT 6170- ASAD
- 1 -
© HY 2010
Lecture 3
Convener:
Houman Younessi
1-860-548-7880
Advanced Systems
Analysis and DesignFall 2010
MGMT 6170- ASAD
- 2 -
© HY 2010
Lecture 3
Requirements Elicitation and CaptureOne of the most serious – if not the most serious – technical risks facing the software engineer is inadequate understanding of the problem situation and user requirements.
Clear and comprehensive elicitation of requirements is therefore one of the most fundamentally important activities of software engineering.
This is unfortunately very difficult and inherently problematic due to:
Ambiguity
Volume
Incompleteness
Inconsistency
MGMT 6170- ASAD
- 3 -
© HY 2010
Lecture 3
Requirements ElicitationAccording to Davis(1982), there are four basic approaches to requirements elicitation:
The Asking Strategy
The Deriving Strategy
The Analyzing Strategy
The Prototyping Strategy
Each of these strategies could be implemented using various techniques. Whilst we shall briefly introduce each, It should be noted that at all times a mix of strategies and techniques are used for effective requirements elicitation.
MGMT 6170- ASAD
- 4 -
© HY 2010
Lecture 3
Requirements Elicitation
The Asking Strategy:
This is when the system developer would elicit requirements by asking the customer or its representatives (domain experts). Some techniques belonging to this category would be:
Interviewing
Questionnaires
Group Meetings, Nominal Group Technique and Joint Sessions
MGMT 6170- ASAD
- 5 -
© HY 2010
Lecture 3
Requirements Elicitation
The Deriving Strategy:
The deriving strategy is the technique of using existing system examples and procedures to extract (derive) the requirements of the system to be built. Some techniques include:
Observation and temporary assignment
Inspecting documents
Inspecting software
Research in the field.
MGMT 6170- ASAD
- 6 -
© HY 2010
Lecture 3
Requirements Elicitation
The Analyzing Strategy:
This strategy studies the aims and objectives of the organization or a unit and determines how these may be achieved in terms of inputs, outputs, operations, decisions and interactions with other units. In other words given an objective for a system we analyze what such a system should be and what it should do. Some techniques include:
Critical Success Factors
Systems Dynamics
Information Systems Planning
MGMT 6170- ASAD
- 7 -
© HY 2010
Lecture 3
Requirements ElicitationThe Prototyping Strategy:
This is a strategy in which we involve the users to react to a mock up (a limited functionality system or part thereof) created to reflect the developers’ current understanding of what the system should look like and do.
Prototyping tools or software appropriate for rapid development is usually used.
It is essential to resist the temptation to use the prototypes created for this purpose as part of the delivered system. Prototyping is a way of finding out what the problem is not what the solution would be.
MGMT 6170- ASAD
- 8 -
© HY 2010
Lecture 3
InterviewingInterviewing is one of the most important techniques available to the requirements engineer. It is very flexible and powerful when used properly.
It is an art, however, which can easily go wrong, and to do it well requires training and practice.
Purposes of interviews:
Data Collection
Verification
Influencing opinion
Encouraging and promoting customer participation
MGMT 6170- ASAD
- 9 -
© HY 2010
Lecture 3
Interviewing
Stages of interviewing:
1. Planning
Read all relevant background material
Decide who to interview
Establish the interview objective
Book a time and place with the interviewees
Decide what questions to ask
MGMT 6170- ASAD
- 10 -
© HY 2010
Lecture 3
Stages of interviewing:
2. Conducting the interview
Make the interviewees feel comfortable
Explain the purpose of the interview
Keep control of the interview; allow diversion only when useful
Request permission to take notes (tape recording is rarely agreed to but if allowed can be very useful)
Request copies of important documents discussed
Be aware of body language
Close at the agreed time, agree on any further action required
Interviewing
MGMT 6170- ASAD
- 11 -
© HY 2010
Lecture 3
Stages of interviewing:
3. Post Interview activities
Write a report on the interview as soon as possible after the interview
Send a copy of the report to the interviewee
Actively seek verification of accuracy and completeness of the contents
Interviewing
MGMT 6170- ASAD
- 12 -
© HY 2010
Lecture 3
Joint Sessions
A Joint Session is an approach to gathering data from users at a workshop intended to promote interaction between various customer and developer stakeholders. The key principal behind Joint Sessions is “User Involvement”. The basis stages are:
1.Planning and preparation:
Plan the objectives and the scope of the workshop
Select appropriate user participants
Prepare and distribute workshop agenda and background material
Arrange facilities and book session with participants
MGMT 6170- ASAD
- 13 -
© HY 2010
Lecture 3
Joint Sessions
2. Conduct the Joint Session workshop:
Introduce the session and participants
Describe the session objectives and ground rules (the project sponsor may do this)
Manage the agenda and maintain the group’s focus
Issues, agreed facts, requirements, ideas etc. are written down on a whiteboard or a butcher’s paper
Conclude the session with a review of issues raised and agreed.
MGMT 6170- ASAD
- 14 -
© HY 2010
Lecture 3
Joint Sessions
3. Document the Workshop Results and Follow-up
Compose and send all information gathered during the workshop to the participants for verification
Assess the workshop outputs and determine whether further sessions are required.
There are a number of roles that are played within a Joint Session. These are:
Session Facilitator User project sponsor
Scribe User participants
Observers
MGMT 6170- ASAD
- 15 -
© HY 2010
Lecture 3
Joint SessionsSession Facilitator:
Guides the session, ensuring the objectives and agenda are kept
Must remain neutral, not adding any personal views or information to the data collected
Introduces and concludes the session
Encourages all users to participate
Scribe:
Supports the facilitator by visibly documenting all facts, issues and concerns during the workshop
Ensures that the session workshop room has appropriate facilities and equipment.
MGMT 6170- ASAD
- 16 -
© HY 2010
Lecture 3
Joint SessionsUser Project Sponsor:
This is usually a senior manager or executive from the business who is funding the project. The project sponsor;
Confirms the project and session objectives and scope
States the business need and commitment from customer management view point.
User Participants:
These people provide the user business expertise or technical know-how. There could be from 4 to 15 user participants. They:
Know the business areas impacted
Have the authority to agree on actions on behalf of the business
MGMT 6170- ASAD
- 17 -
© HY 2010
Lecture 3
Joint SessionsObservers:
This is an optional role. Usually outside experts in the field, or in software technology, they must remain silent unless specifically asked to provide input.
Observer
User Participants
Session Facilitator
Scribe BoardA typical layout for a Joint Session
MGMT 6170- ASAD
- 18 -
© HY 2010
Lecture 3
Document InspectionIf a computer systems development project involves analyzing an existing manual or computer system, there will be existing documentation to inspect. This can serve as a good starting point to the systems investigation and can provide a high volume of high quality data at virtually no cost.
Types of documents to inspect include:
Organization Charts Training course materials
Procedure manuals Reports generated by staff and system
Job descriptions System manuals
Forms Financial records
MGMT 6170- ASAD
- 19 -
© HY 2010
Lecture 3
Document InspectionEach document will have its own life-cycle of creation, amendments, use and deletion. Questions that might be asked include:
What event initially triggered the creation of this document?
Who generates the document?
How is it prepared?
Where is the data derived from?
Who uses the document?
What purpose does the document serve?
How and where is it stored and why?
How long is it kept for?
Do not just computerize the existing system
MGMT 6170- ASAD
- 20 -
© HY 2010
Lecture 3
Requirements Capture
Once software requirements are elicited, they must be captured and documented in a clear, unambiguous and accessible way. This is called Requirements Capture or Requirements Documentation.
There are several popular techniques available:
Simple Narrative
Enhanced narrative, including:
Scenarios and Usecases
Pictures, diagrams and cartoons
Formal Language
MGMT 6170- ASAD
- 21 -
© HY 2010
Lecture 3
Requirements Capture
Simple Narrative:
Simple narrative is precisely that: simply narrating in text, our understanding of the requirements. A document containing a narration of the important aspects of the system required by the client will be the result of such an approach. Usually called a requirements definition document.
Although possibly sufficient for very small and simple systems, this approach soon becomes insufficient for capturing the requirements of a large and complex system.
MGMT 6170- ASAD
- 22 -
© HY 2010
Lecture 3
Requirements CaptureProblems and limitations of the simple narrative approach:
Ambiguity
Volume
Incompleteness
Inconsistency
TediumWe can enhance such a document easily and solve, at least partially, some of these problems.
MGMT 6170- ASAD
- 23 -
© HY 2010
Lecture 3
We can improve things through a number of enhancements.
Logical organization:
This can improve the readability, reduce tedium, ambiguity and volume. Some inconsistencies may also be identified and removed.
Taking a systems approach:
This can improve completeness, help with ambiguity and inconsistency. It may also somewhat reduce volume.
Requirements Capture
Enhanced Narrative:
MGMT 6170- ASAD
- 24 -
© HY 2010
Lecture 3
Requirements CaptureLogical Organization:
One way to logically organize the requirements is to recognize that there are several types of requirements each dealing with a specific quality aspect of the system. These include:
Functional Requirements
Usability Requirements
Reliability Requirements
Maintainability Requirements
Often times (and mistakenly) only the functional requirements are spelt out.
Usually we group requirements into two basic groups: functional and non-functional. Of these types on the right the three in the bottom box are all non-functional requirements.
Other non functional requirements might be related to hardware and the physical system or the development process.
MGMT 6170- ASAD
- 25 -
© HY 2010
Lecture 3
Requirements CaptureAnother way is to recognize that not all requirements MUST be delivered. We could in fact rate requirements as “absolute”, “desirable”, and “nice to have”. We could attach a numerical value to each or use a wider or indeed narrower nominal scale.
Another way is to use a logical hierarchy to keep the requirements that relate to each other logically together. E.g. all account related requirements together, and within that all interest rate related requirements together again. A hierarchical mnemonic system might be helpful here. E.g. R8.4.12F1,R8.4.12U2, etc.
Needless to say, it is possible to use all these logical organization schemes together.
MGMT 6170- ASAD
- 26 -
© HY 2010
Lecture 3
Requirements CaptureTaking a systems approach:The problem situation to be understood may be looked at from a systems perspective.
This means that we can look at the problem in terms of its boundaries, interactions, transformations and other systems properties in an attempt to describe it as a system. This system description, which would be a model of the system required, would then be used to convey the requirements. But note:
The system model “conveys” the requirements but the actual individual requirements must be “deduced”.
Obviously, only functional requirements can be thus deduced, at least for the most part.
MGMT 6170- ASAD
- 27 -
© HY 2010
Lecture 3
Requirements CaptureStructural Modeling:This is a modeling approach in which those elements of the system that describe its structure; that is the entities that the system is conceived to be or will be built from, and the relationship between these, are modeled.
Transformational Modeling:This is a modeling approach in which the system is described in terms of its boundary, inputs, processes that take place over these inputs, and its outputs.
Temporal (Causal)Modeling:This is a modeling approach in which the cause and effect relationships within the system is modeled.
We usually use a graphical language to depict these models. Much more will be said about these modeling approaches in future lectures.
MGMT 6170- ASAD
- 28 -
© HY 2010
Lecture 3
USE CASES
Use cases are an important component of many software requirements capture methods, particularly those following the object oriented paradigm. For example, the RUP incorporates them as an essential part. In fact the RUP is use case driven.
Use cases define the interaction between the user and one end to end transaction with the system of interest.
Requirements Capture
MGMT 6170- ASAD
- 29 -
© HY 2010
Lecture 3
We must make a distinction between use cases and use case diagrams. Although conceptually related, one is a technique of understanding the problem domain and an integral part of many OO processes including RUP, the other is a diagramming technique of some modeling languages, including UML.
Use case diagrams, if drawn correctly, can however enhance the usability of use cases greatly.
Use cases v. Use case diagrams
Requirements Capture
MGMT 6170- ASAD
- 30 -
© HY 2010
Lecture 3
A use case is an essentially narrative document.
It describes the sequence of abstracted events of an abstracted actor (user) using the system in order to complete a task. Thus use cases are concerned with use of the system and not with the processing that takes place.
Use cases may be high level (dealing with a major utility of the system), or expanded (dealing with an individual task or even sub-task).
Requirements Capture
MGMT 6170- ASAD
- 31 -
© HY 2010
Lecture 3
Constructing use casesThis is where opinions differ. There are essentially three approaches:
• Identify the actors (users of the system) first and then for each, identify the interaction they have with the system to achieve their goals. Each such iteration will yield a high level use case.
• Identify the major deliverables of the system, and then the actors and interactions required to produce each.
• Start the structure modeling process to help uncover the use cases.
Requirements Capture
MGMT 6170- ASAD
- 32 -
© HY 2010
Lecture 3
Entity external to the system that interacts with it to complete a coherent (need not be atomic) task or work unit.
The entity that starts off the use case.
A label or identifier for the use case.
The narration of the events that define the use case.
Actor:
Initiating Actor:
Name:
Description:
Requirements Capture
MGMT 6170- ASAD
- 33 -
© HY 2010
Lecture 3
Example expanded use case:
Use case: Check credit, is OK
Actor: Salesperson
Initiating Actor: Salesperson
Description: Salesperson checks the customer creditworthiness (See Check with CAS). then (s)he checks the the credit limit of the customer (See Check Credit Limit).
Requirements Capture
MGMT 6170- ASAD
- 34 -
© HY 2010
Lecture 3
Use case: Check credit, not OK
Actor: Salesperson
Initiating Actor: Salesperson
Description: Salesperson checks the customer creditworthiness (See Check with CAS). Then (s)he suspends the order (See Suspend Order).
Requirements Capture
Example expanded use case:
MGMT 6170- ASAD
- 35 -
© HY 2010
Lecture 3
Alternate style:
Use case: Check credit, is OK
Actor: Salesperson
Initiating Actor: Salesperson
Description: 1. Check customer creditworthiness.
1.1 See check with CAS
2. [OK], then check credit limit
2.1 See check credit limit
Requirements Capture
MGMT 6170- ASAD
- 36 -
© HY 2010
Lecture 3
Use case: Check credit , not OK
Actor: Salesperson
Initiating Actor: Salesperson
Description: 1. Check customer creditworthiness.
1.1 See check with CAS
2. [not OK], then suspend the order
2.1 see suspend order
Requirements Capture
MGMT 6170- ASAD
- 37 -
© HY 2010
Lecture 3
Use case: Check credit
Actor: Salesperson
Initiating Actor: Salesperson
Description: 1. Check customer creditworthiness.
1.1 See check with CAS
2. If OK, then check credit limit
2.1 See check credit limit
3. If not OK, see suspend order
Sometimes we may combine two or more conditions:
Requirements Capture
MGMT 6170- ASAD
- 38 -
© HY 2010
Lecture 3
Use cases and particularly expanded use cases may be categorized into two categories:
• Normal course (normal use)
• Non-normal course
Example: Use an ATM to withdraw cash from check account (normal), withdrawal limit exceeded (non- normal)
Requirements Capture
MGMT 6170- ASAD
- 39 -
© HY 2010
Lecture 3
Requirements CaptureDiagrams and cartoons
A picture is worth a thousand words
Sometimes we use graphical aids to describe what we mean. We can do the same when capturing software requirements. There are essentially three types of graphic types that fall under this category:
Model diagrams (they usually depict the system)
Support diagrams (they usually enhance understandability of a work-product or usability of a technique which could exist independently of the diagram)
Informal diagrams, cartoons and rich pictures (they usually depict a situation or a set of situational relationships)
MGMT 6170- ASAD
- 40 -
© HY 2010
Lecture 3
Model diagrams
Requirements Capture
These are literally graphical languages. They have certain icons to depict various elements required of the model to be constructed and a set of rules to combine them to make more complex but still meaningful diagrams, eventually yielding a model of the system.
There are many types of such diagrams. Three types however are paramount: Structure diagrams, Transformational diagrams and Causal or Dynamic diagrams which are naturally the corresponding graphical depictions for Structure models, Transformational models and Causal models.
There are many different conventions for each type. We shall cover the “standard” version of each type in the next two lectures.
MGMT 6170- ASAD
- 41 -
© HY 2010
Lecture 3
Requirements Capture
Support diagrams
A support diagram is one that enhances a work-product or helps with its understandability or assists the usability of a particular technique. Again many of these exist, of which several are of importance. We shall name these here and defer their discussion to a more appropriate time as these are best described in conjunction with their corresponding technique or work-product.
Use-case diagrams Fern diagrams
Sequence diagrams Context diagrams
Fishbone diagrams
MGMT 6170- ASAD
- 42 -
© HY 2010
Lecture 3
Requirements CaptureInformal diagrams, cartoons
It is often useful, for example during an interview, to jot down quickly a drawing that captures the essence of a requirement or some aspect of the system without necessarily being formal about the syntax of the diagrams. We can draw little flow charts, diagrams of how a screen may look like, a truth table to capture some logical condition, etc. We could draw a cartoon depicting (sometimes with appropriate exaggerations) the situation, some interaction or set of interactions, etc. These cartoons can be stylized, or not, structured or otherwise. A uniformly stylized, structured cartoon of a situation is sometimes called a rich picture. E.g. System Architecture diagrams.
MGMT 6170- ASAD
- 43 -
© HY 2010
Lecture 3
Requirements CaptureFormal Languages:
It often becomes necessary to define a requirement very precisely. The use of mathematical notation to capture the structure, transformations and causal relationships between elements of the model is called formal specification. There are formal languages (using mathematical notions and notations) that can be used in such instances. Again there are many different types, paradigms and styles. The most well developed and widely used are:
Functionally based
Model based
MGMT 6170- ASAD
- 44 -
© HY 2010
Lecture 3
The Requirements Document
Requirements are captured for several reasons. Amongst these are to:
Ensure that our understanding of what is to be done coincides with that of the customer,
Have a basis for writing of contracts,
Be able to convey to our design and implementation colleagues precisely what needs to be developed,
Have a basis for evaluating whether we have completed the project successfully.
MGMT 6170- ASAD
- 45 -
© HY 2010
Lecture 3
To ensure that our understanding of what is to be done coincides with that of the customer, we need an easy to understand and read but not necessarily a very precise document in their language.
To be able to set a basis for contracting, or for evaluating whether we have completed the project successfully or to convey to our design and implementation colleagues precisely what needs to be developed, we need a very precisely worded document in the language of the developers but still understandable by the “expert” customer or their nominee consultants.
It is very difficult to write one document to satisfy both requirements for other than very simple projects. We need two different documents that say exactly the same thing but in two different styles, and level of precision. The first is usually called a Requirements Definition, the second, a Requirements Specification.
The Requirements Document
MGMT 6170- ASAD
- 46 -
© HY 2010
Lecture 3
The Requirements DocumentContents of a Requirements Definition Document:
1. Table of contents and list of figures and tables
2. Preambles, caveats conditions
3. Executive Summary
4. Synopsis of System
5. Current situation and environment (which the system is to improve)
6. Operating environment and conditions (e.g. specialized hardware, security, support )
7. Outline of process to be followed
8. System description (An informal narrative of what the system is to do)
9. High-level system models
10. Functional requirements listing (inc. a statement of measure of success)
11. Non-functional requirements listing (inc. a statement of measure of success)
MGMT 6170- ASAD
- 47 -
© HY 2010
Lecture 3
The Requirements Document
12. Other requirements, constraints or conditions (inc. a statement of measure of success)
13. Post-amble or concluding remarks
14. Appendices:
14.1 Listing of use-cases, State Behavior Definitions and similar artifacts
14.2 All other diagrams and supporting materials
14.3 Glossary of terms and definitions
14.4 Index
14.5 References
MGMT 6170- ASAD
- 48 -
© HY 2010
Lecture 3
The Requirements DocumentContents of a Requirements Specification Document:
1. Table of contents and list of figures and tables
2. Preambles, caveats conditions
3. Description and definition of special notation used, values of constants, etc.
4. Executive Summary
5. Synopsis of System
6. Current situation and environment (which the system is to improve)
7. Operating environment and conditions (e.g. specialized hardware, security, support )
8. Outline of process to be followed
9. High level architecture and System description
10. Expanded system models
11. Precise functional requirements specification (inc. precise statement of measure of success)
MGMT 6170- ASAD
- 49 -
© HY 2010
Lecture 3
The Requirements Document
12. Precise non-functional requirements specification (inc. precise statement of measure of success)
13. Precise specification of other requirements, constraints or conditions (inc. precise statement of measure of success)
14. Post-amble or concluding remarks
15. Appendices:
15.1 Listing of use-cases, State Behavior Definitions and similar artifacts
15.2 All other diagrams and supporting materials
15.3 Glossary of terms and definitions
15.4 Requirements traceability to the Requirements Definition Document
15.5 Index
15.6 References
MGMT 6170- ASAD
- 50 -
© HY 2010
Lecture 3
Requirements Validation
Before we proceed we must be sure, as much as it is possible, that our requirements are accurate and valid. We must ensure that the documents are both internally and externally valid.
Internally valid means that the document is self consistent.
Externally valid means that the document describes the requirements as the customer meant them not just as we, at some stage, may have assumed or understood them.
There are a number of techniques available to help validate requirements.
MGMT 6170- ASAD
- 51 -
© HY 2010
Lecture 3
Requirements Validation
Internal:
Proof reading
Cross-referencing
Checklisting
CRCs
Formal proofs of correctness
Function enactment
External:
Customer Reviews
CRCs
Checklisting
Prototyping
Function enactment
MGMT 6170- ASAD
- 52 -
© HY 2010
Lecture 3
References and Further ReadingHenderson-Sellers, B.; Simons, A.; Younessi, H.; “The OPEN Toolbox of techniques”; Addison-Wesley; 1998.
Davis, G.B.; “Strategies for Information Requirements Determination”; IBM Systems Journal; Vol. 21, No. 1 1982
Rumbaugh, J.; Jacobson, I; Booch, G.; “The Unified Modeling Language reference manual”; Addison-Wesley; 1999.
Graham, I.M.; “Migrating to object technology”; Addison-Wesley; 1995.
Younessi,H.; Smith,R.; Grant,D.; “Towards a systemic approach to object-oriented analysis”; In Proc. 5th Australasian Conf. On Info. Systems; Melbourne, Australia; 1995.
