Wednesday, April 27, 2011

Lecture # 23 Validating Requirements

Lecture # 23 Validating Requirements
It takes 30 minutes to correct a requirement defect in requirement phase
However it may take hours or may be days to correct a defect identified during system testing

A very good practice is to do test planning and create test cases. This reveals defects in requirements early in life cycle.

Validation Attempts to Ensure:
• SRS correctly describes system capabilities
• Requirement are complete and of high quality
• Consistent with each other
• Adequate basis for design and construction

Validation can be done using informal or formal approaches.

Informal approach includes
• Peer Desk check: Ask one colleague to look over your work product
• A passaround: in which you invite several colleagues to examine a deliverable
• A walkthrough: Author describes a deliverable and solicit comments on it

Among Formal Approaches we are going to discuss
• Inspection

Inspection:
• It was first defined by IBM
• Involves small teams of trained participants
• Not specific to requirements but can be used for any software workproduct
• Involves careful examination of work products to discover defects
• A high leverage SQA technique
• It is said that one hour spent in inspection avoids at least 10 hours of labour
• Therefore even being a lengthy task, it should not be avoided
• If there is not enough time, then risk analysis should be done to identify critical requirements and then inspection of those should be performed
• Inspection should not wait for the entire SRS to complete but it should be started as soon as 10% of SRS gets completed.

Participants of Inspection:
Should involve people having different perspectives
Normally four people are involved however the total number of people involved should not exceed 6

People involved can be
• Author or peer of author
• Author of any predecessor work product, e.g. person who document high level requirements
• People who will do work based upon item being inspected
• People who are responsible for work products that interface with items being inspected

Roles involved
Some tasks are delegated to people with in the inspection team
1- Moderator (Inspection leader)
a. Plans inspection with author
b. Coordinates and facilitates activities
c. Distributes the material, days before the meeting
d. Responsible for right focus of meeting
e. Reporting results
f. Follows up with author so that defects and issues raised are addressed
2- Author
a. Much passive role
b. Listens and responds to questions
c. Spotting errors that others don’t see
d. Incorporating the recommendations
3- Reader
a. Reads a requirement at a time
b. Paraphrases, that is explains in his own words
c. Other participants point out defects and issues
4- Recorder (Scribe)
a. Documents issues raised
b. Reads aloud what he has wrote to confirm accuracy

Pre-requisites of Inspection:
Avoids spending time on issues that can be solved before
Moderator should the following before proceeding
1- Document confirms to standard template (If any)
2- Spell checked
3- Layout errors resolved
4- Reference documents required by inspectors are available
5- Line numbers printed
6- Open issues are marked as TBD (To be determined)
7- Moderator did not find 3 major defects in 10 min of time

Inspection Stages
1- Planning
2- Overview Meeting
3- Preparation
4- Inspection Meeting
5- Rework
6- Followup

Monday, April 25, 2011

Lecture # 21 Ways of Developing Prototypes

There are three possible ways of developing prototypes
1. Paper Prototype
a. Cheapest but effective
b. No executable software
c. Paper version needs to be developed
d. Usage scenarios are planned and drawn
e. Analyst may guide the end-user through the drawn scenarios explaining how particular tasks can be completed through the system
2. Wizard of OZ prototype
a. Relatively cheap
b. Usually used when a legacy system is being replaced by a newer one
c. A new user interface is developed
d. The input accepted by interface is then taken up by a person who generates responses, may be after getting them from the old system.
3. Automated/Executable prototype
a. Most expensive
b. Executable product is developed
c. Can be evolved into actual system

Lecture # 20 Prototyping

Prototyping can help elicit and validate requirements
For a prototype, it is necessary that it gets developed quickly, therefore
• Prototypes normally include necessary functions only
• Many management practices and Quality Assurance practices are skipped
• Non functional requirements are ignored
• Sometimes it may be developed using a different technology so that development time is saved.
Benefits of Prototypes
• Allows customer and end-user to experiment thus providing them with an opportunity to refine and improve their requirements.
• Customer can get an idea of how system can be used.
• Suggests overall feasibility and usefulness
• Effective way of developing user interface
• Ensures effective testing
• Since requires careful study thus reveals inconsistencies thus lesser requirement reworks
Problems
• Training is required if the team does not have experience of developing prototypes
• Additional time is required
• May cause delay as development team can get stuck into an infinite loop, where client suggests further improvements and requirements on each delivery of prototype
• Misleading as the emergent behavior may be different from actual product. For example actual payroll calculation for all employees of company may take a lot of time however since the prototype is not considering all records or may be all rules therefore payroll calculation will take less time. The end user may be mislead by this may begin to expect that payroll calculation will always take this much time.
• Can be used majorly for functional requirements
Categories of Prototypes
Throwaway

• Discarded when final system has been developed
• Helps elicit and develop system requirement
• Usually requirements that are hardest to understand are included so that real expectation of client is determined
• Such features are included that are most crucial in terms of difficulties the customer may face while using them.
Evolutionary
• Deliver workable system quickly
• This prototype will be evolved into the actual system rather than developing the system from scratch after refinement of requirement (contrary to Throw-Away prototype).
• Features that are well understood are included
• Features that can deliver useful functionality to end-user are included

Lecture # 19 Activities of Requirement Elicitation

There cannot be a single process of requirement elicitation that can act as a silver bullet. However authors have suggested some activities that must be done while doing requirement engineering
1. Objective Setting:
a. Identifying general goals of business
b. Outline of problem to be solved and need of problem to be solved
c. Identification of constraints including budget, schedule and interoperability
2. Background knowledge Acquisition
a. Acquiring Information regarding the organization
b. Acquiring information regarding application domain
c. Gathering knowledge about existing system that will be replaced
3. Knowledge Organization
a. Organizing large amount of knowledge acquired
b. Involves identifying system stakeholders
c. Prioritizing goals
d. Discarding unnecessary domain knowledge which do not contribute to system requirement
4. Stakeholder requirement collection
a. Involves consulting system stakeholders to discover their requirements
As a result of requirement elicitation a large amount of data is collected. In order to make the data more meaningful, it is important that the organized and structured.

Following are the ways to structure data
1. Partitioning
a. Aggregation relationship. For example in University, a degree is made up of a number of courses. Payroll of a single employee is made up of a number of earnings
2. Abstraction
a. General / Specific Relationship. For example a university offers a Degree which has a number of categories e.g. PH.D., Masters, Bachelors etc. Each category has some special characteristic
3. Projection
a. Organization of knowledge from several different perspectives, For example, information from the perspective of student, details from the perspective of faculty and information with respect to examination etc.

Tuesday, April 12, 2011

UML 3rd & 4th Lecture Scenarios

Use-Case Specification/Description
(Note: Proof Reading will be done soon)

Scenario # 1

Maintenance requests are forwarded by consultant to developer. The developer gives response to request after doing analysis of the request. If the request is something which is doable the developer calculates and gives estimates (Time) to consultant. Incase the request can not be entertained, the developer informs the consultant.
Forwarding request involves recording information about request on an excel sheet and emailing details of request to developer.

Scenario # 2

While issuing admit card the account department checks fee payment and checks attendance. If the fees is paid and attendance is complete then admit card will be issued. If fees is not paid then student has to submit an undertaking identifying the date by which fees will be submitted after which admit card will be issued. Incase student is short of attendance the account department may ask for medical certificate to know the reason of absence. If the reason is not valid the admit card will not be issued.

Scenario # 3

An associate can add information regarding contacts. He can also update the status of contact to a prospect or client. When the status of contact is updated it is shifted from public list to private list of associates. If the contact was already in communication with other associates then an email will be sent to all the other associates in order to inform that they can no longer do business with contact.

Scenario # 4

On receiving an order the salesman packages the goods and creates a bill. If it is found that the items are not available in the shop then they are brought from warehouse before creating package. In addition, if after creating package of goods it is found that specific goods are not left in shop then they are brought from warehouse.






Activity Diagram

Scenario # 1

While processing an order a salesman determines price of individual items and calculates the total amount of bill. If the amount of bill exceeds 5000 then a discount of 10% is offered. Salesman also checks if the customers process a “Valued Customer Card”. If the customer is valued customer then 10% discount is offered.

Scenario # 2

Employee submit leave application manager approves leave application and forwards it to HR department which performs deductions of leaves.

UML Lecture# 2 Use Case Diagrams

A Use Case diagram models the functionality of the system as perceived by outside users, called actors. • Use case diagrams – Highlight the functional requirements of the system i.e. what the system should do – Since it records “what the system should do”, thus it become the basis for performing tests that verify whether the system doing what the user expects – Pthe ability to trace functional requirements into classes and operations • Audience of Use Case diagram – Clients can see the use case diagram to confirm whether the system will do what they expect – Quality Assurance Team may refer to use case diagrams while verifying whether system meets the expectations of clients – Architects may use the diagram to see what functionality should be made available to various users Components of a use-case diagram • Use-cases – Represents a complete functionality as perceived by an actor – It encapsulates a description of a set of sequence of actions, including variants that the system performs to yield an observable value to an actor. The sequence and variants are documented in a use case specification • Actor – representing a role that someone might play, rather than a particular individual – external entity that has interest in interacting with the system – Someone who gives input or receive any output from the system • Interaction – a communication relation between an actor and a use case Drawing a use case diagram • The first step is to identify the actors • Then we should identify the activities that are initiated by actor or the activities whose output is received by an actor. • It should be seen whether any sub activities are performed or whether some actions are performed in special situations Use Case Relationships A use case is usually associated with an actor. This association is known as communications associations The navigation direction of an association represents who is initiating the communication Relationships also exist between use cases Generalization relationship: Sometimes certain use case is a specialized version of another use case. For example, Conduncting a Test is a general situation whereas a Conducting a Mid-Term is a special situation that has all the processes/steps of Test as well as some additional steps/ Include – Base use case explicitly incorporates the behavior of another use case – It enables us to avoid describing the same flow of events several time by putting the common behavior in a use case of its own • Extend – An extend relationship between use cases means that behavior of another use case is conditionally incorporated in the base use case – Use an extend relationship to model the part of a use case the user may see as optional system behavior

Monday, April 4, 2011

Lecture # 18 Problems in Each Dimension

Objective -Understand problem in each dimension Introduction While gathering information from various dimensions, a number of problems are faced. Following section enlists the problems under relevant headings Problems in Application Domain • Knowledge is scattered in books, brains and manuals • Problems are also faced while referring to these sources because the presence and usage of specialist terminologies. For example, while making a system for managing financial products a developer may encounter terms like Premium, On Risk Date, Income Protection etc. In order to better understand documents etc. such terms may first be understood. Problems in Problem Analysis People who understand the problem are sometimes so busy or they have some deadlines to meet because of which they have less priority for sharing information with requirement engineer In some situations, they may not be convinced that the system is necessary/useful, therefore they resist its development by avoiding sharing information or in some cases correct information Problems in Business Understanding: • Higher management may try to present requirements in such a way that they gain more control. They initially decided and main objectives may be different but higher management may latter realize that there is an opportunity of getting other advantages from the system. Thus they will try to include additional requirements that may to contribute in achieving the actual objectives of the system. Problems in Understanding Stakeholder Constraints and Needs: • It is a common observation that stakeholders don’t really know what they want or in some cases they find it difficult to articulate their needs and wants. • It has also been observed that they have unrealistic demands because they are not aware of the technology constraints. For example the client may demand a mobile application that allows users dictate SMS. This application is technically impossible with the current technology. • One other issue is that same requirement is expressed differently by various stakeholders belonging to various levels of organization. Other problems • Economic and business environment changes, this may affect the importance certain requirements or even certain applications. To understand this, let’s discuss an example out of the IT domain. A recording company decided that it would make cassettes by itself and it started working on this project. While they were in the initial stages of this project, CDs came into the market and soon it became clear that CDs will replace cassettes. The business will now lose its interest in the project related to cassettes as it will not be worth spending money on it. • Requirements from new stakeholders who were not originally consulted • People who were consulted initially changed their jobs • Stakeholders forget what they said. For example, one of our clients indicated that some fields must have defaulted to commonly used values so that users don’t have to type everything. However at a later stage of project they complained (forgetting that it was their own demand) that because of the default values end-users do not fill the complete form and they leave the default values as they are.