Describe Requirement Discovery

Requirements discovery includes those techniques to be used by systems analysts to identify or extract system problems and solution requirements from the user community.

 

A system requirement (also called a business requirement)is a description of the needs and desires for an information system. A requirement may describe functions, features (attributes), and constraints

 

 

A functional requirement is a function or feature that must be included in an information system in order to satisfy the business need and be acceptable to the users.In software engineering, a functional requirement defines a function of a software system or its component. A function is described as a set of inputs, the behavior, and outputs. Functional requirements may be calculations, technical details, data manipulation and processing and other specific functionality that define what a system is supposed to accomplish. Behavioral requirements describing all the cases where the system uses the functional requirements are captured in use cases

 

Functional requirements are supported by non-functional requirements (also known as quality requirements), which impose constraints on the design or implementation (such as performance requirements, security, or reliability)

 

A nonfunctional requirement is a description of the features, characteristics, and attributes of the system as well as any constraints that may limit the boundaries of the proposed solution.

 

 

Performance requirements represent the performance the system is required to exhibit to meet the needs of users eg.

What is the acceptable throughput rate?

What is the acceptable response time?

 

Information requirements represent the information that is pertinent to the users in terms of content, timeliness, accuracy, and format. eg.

What is the required data to be stored?

What are the necessary inputs and outputs?

When must they happen How current must the information be? What are the interfaces to external systems?

 

Economy requirements represent the need for the system to reduce costs or increase profits.

What are the areas of the system where costs must be reduced?

How much should costs be reduced or profits be increased? What are the budgetary limits?

What is the timetable for development?

 

 

Control requirements represent the environment in which the system belongs

What are the privacy requirements?

Does the criticality of the data necessitate the need for specialhandling (backups, offsite storage, etc.) of the data?

 

 

Consistent – not conflicting or ambiguous.

Complete – describe all possible system inputs and responses.

Feasible – can be satisfied within available resources and constraints.

Required – truly needed and fulfill the purpose of the system.

Accurate – stated correctly.

Traceable – directly map to the functions and features of the system.

Verifiable – defined so they can be demonstrated during testing

 

Documenting and analyzing requirements

 

 

The Ishikawa diagram is a graphical tool used to identify, explore, and depict problems and the causes and effects of those problems. It is often referred to as a cause-and-effect diagram or a fishbone diagram.

 

Documenting the draft requirements with various tools:

 

Use cases

Decision tables

Requirements tables

 

Analyzing requirements to resolve problems of:

 

Missing requirements

Conflicting/Overlapping requirements

Infeasible requirements

Ambiguous requirements

Formalizing requirements

 

 

Requirements Creep (sometimes known as Feature creep or scope creep) is a tendency for product or project requirements to increase during development beyond those originally foreseen, leading to features that weren't originally planned and resulting risk to product quality or schedule. Feature creep may be driven by a client's growing "wish list" or by developers themselves as they see opportunity for improving the product.

 

 

Fact-Finding often brings systems analysts into contact with sensitive information. Company plans ,Employee salaries or medical history Customer credit card, social security, or other information.

 

 

1.Sampling of existing documentation, forms, and databases.

2.Research and site visits.

3.Observation of the work environment.

4.Questionnaires.

5.Interviews.

6.Prototyping.

7.Joint requirements planning (JRP).

 

 

Sampling the process of collecting a representative sample of documents, forms, and records. Organization chart Memos and other documents that describe the problem Documentation and Standard operating procedures for current system Completed forms Manual and computerized screens and reports Samples of databases.

 

Sampling Techniques

 

Randomization :a sampling technique characterized by having no predetermined pattern or plan for selecting sample data.

Stratification :a systematic sampling technique that attempts to reduce the variance of the estimates by spreading out the sampling—for example, choosing documents or records by formula—and by avoiding very high or low estimates 

 

 

Observation :a fact-finding technique wherein the systems analyst either participates in or watches a person perform activities to learn about the system.

 

Observation Guidelines

 

1.Determine the who, what, where, when, why, and how of the observation.

2.Obtain permission from appropriate supervisors or managers.

3.Inform those who will be observed of the purpose of the observation.

4.Keep a low profile.

5.Take notes during or immediately following the observation.

6.Review observation notes with appropriate individuals. 7.Don't interrupt the individuals at work.

8.Don't focus heavily on trivial activities. Don't make assumptions

 

 

A special-purpose document that allows the analyst to collect information and opinions from respondents.

Free-format questionnaire a questionnaire designed to offer the respondent greater latitude in the answer. A question is asked, and the respondent records the answer in the space provided after the question.

Fixed-format questionnaire a questionnaire containing questions that require selecting an answer from predefined available responses

 

Interviews

 

A fact-finding technique whereby the systems analysts collect information from individuals through face-to-face interaction. Find, verify, clarify facts Generate enthusiasm Get the end-user involved Identify requirements Solicit ideas and opinions

 

Types of Interviews

 

Unstructured interview an interview that is conducted with only a general goal or subject in mind and with few, if any, specific questions. The interviewer counts on the interviewee to provide a framework and direct the conversation.

Structured interview an interview in which the interviewer has a specific set of questions to ask of the interviewee.

 

Open-ended question question that allows the interviewee to respond in any way that seems appropriate.

Closed-ended question a question that restricts answers to either specific choices or short, direct responses

 

Discovery prototyping – the act of building a small-scale, representative or working model of the users’ requirements in order to discover or verify those requirements.

 

Joint requirements planning (JRP)

 

A process whereby highly structured group meetings are conducted for the purpose of analyzing problems and defining requirements. JRP is a subset of a more comprehensive joint application development or JAD technique that encompasses the entire systems development process

 

Steps to Plan JRP

 

Selecting a location Away from workplace when possible Requires several rooms Equipped with tables, chairs, whiteboard, overhead projectors

Needed computer equipment Selecting the participants

Each needs release from regular duties

Preparing the agenda Briefing documentation

Agenda distributed before each session