Requirement Documentation

Name: Rahul Gupta Section: RK3901 Roll No.: B40 Lovely Professional University Phagwara

Abstract: From the research on my topic I

study the various topics on the Requirement Documentation. I concluded that Requirement Documentation is a great importance in Software development.

Introduction
The requirements of a software product are a list of features required by the customer. One or more managers/software engineers will usually sit down with the customer to get a list of exactly what the product should do and how it should do it.

The development team will later use these requirements to design the software around the customers' expectations.

Problems in developing computer based systems since 1960s

Too many systems are late or over budget Systems don't do what the users really want or never used to the effectiveness There are rarely a single reason for these problems but a major contributory factor is difficulties with system requirements.

What is requirements engineering?

A relatively new term invented to cover all of the activities involved in discovering, documenting and maintaining a set of requirements for a computer-based system. Use of the term 'engineering' implies that systematic and repeatable techniques should be used to ensure that system requirements are complete, consistent and relevant.

What are requirements?

A specification of what should be implemented Defined at early stages of a system development Include: how the system should behave application domain information constraints on the system's operation specification of a system property or attribute.

How much does requirements engineering cost?

Depends on the type and size of the system being developed In a survey for large hardware/software systems, about 15% of the total budget is taken up by the requirements engineering activities. For smaller projects it is about 10%.

Common requirements' problems

Don't reflect the real needs of the customers Inconsistent and incomplete Expensive to make changes to the requirements after they have been agreed

What is a requirements engineering process?

Requirements engineering process is a structured set of activities which are followed to derive, validate and maintain a systems requirements document. The activities include: Requirements elicitation

Misunderstandings between customers, those developing the system requirements and software engineers Requirements analysis and negotiation Requirements documentation Requirements validation

What happens when requirements are wrong?

System may be delivered late or with more cost than originally expected Customer and end-user might not be satisfied with the system System may be unreliable in use, with regular system crashes happening all the time. If system continues in use, the costs of maintaining and evolving are usually very high.

Requirements elicitation techniques

The system requirements are discovered through consultation with stakeholders, from system documents, domain knowledge Other names are 'requirement acquisition' or 'requirement discovery'

Requirements Reuse
A good practice to reuse as much knowledge as possible when developing a new system Although requirements for each system is distinct, there are a number of situations where reuse is possible: Where requirement is concerned with providing information about the application domain, e.g. constraints on the system. Where the requirement is concerned with the style of presentation of the information, like the user interface of the whole systems for an organization. Where the requirements reflect company policies such as security requirements.

'throw-away' prototypes used to help elicit and analyze the requirements are often called In contrast evolutionary prototypes are intended to deliver a workable system quickly to the customer Prototypes help to establish the overall feasibility and usefulness of the system The only effective way of developing system user interface. May be possible to be used in system tests later in the validation process

Prototyping
An initial version of the system which is available early in the development process Helps elicit and validate the system requirements

Requirements analysis and negotiation

Aim at discovering problems with the system requirements and reach agreement on changes to satisfy all system stakeholders Requirements are analyzed in detail Different stakeholders negotiate to decide on which requirements are to be accepted Since there are inevitably conflicts between the requirements from different sources, information may be incomplete or may be incompatible with the budget available

Use of non-standard software/hardware Requirements ambiguity Conformance with business rules Requirements testability Requirements realism

Requirements negotiation
Discussing conflicts and finding some compromise which all of the stakeholders can live with Meetings are most effective way. Meetings should be conducted in three stages: An information stage, explaining the nature of the problem A discussion stage, in which stakeholders discuss possible

Analysis checklists
A list of questions which the analyst may use to assess the requirement. Some items in these lists may be: Premature design Combined requirements Unnecessary requirements

solutions A resolution stage, where actions concerning the requirements are agreed

Requirements Documentation
There are many different ways to structure the requirements documents, depending on: The type of the system being developed The level of detail included Organizational practice Budget Schedule

structure is consistent with defined standards Review team membership: Stakeholders from different disciplines should be involved

User manual development

User manual development: Rewriting the requirements in a different way is a very effective validation technique. To rewrite the document you must understand the requirements and the relationships. Developing this understanding reveals conflicts omissions and inconsistencies. A user manual should include the following information: A description of the functionality and how to

Requirements validation
The process outputs are as follows: A list of problems Agreed solution Techniques for requirements validation: Requirements reviews: Involves a group of people who read and analyze the requirements Pre-review checking: one person carries out a quick standards check to ensure that the documents

access the functionality through the user interface A description of how to recover from difficulties Installation instructions for users

that readers have the same background and knowledge as you Writing clearly and concisely is not easy. Allow sufficient time for drafting and reviewing

Guidelines
Define standard templates for describing requirements Use language simply, concisely and consistently. Use short sentences and paragraphs Use diagrams appropriately to present overviews and relationships between entities

Common problems in writing requirements

Requirements are written in complex conditional clauses which are confusing Terminology is used in a sloppy and inconsistent way The writers of the requirement assume that the reader has specific knowledge of the domain of the system and may leave out some essential information

Specify requirements quantitatively (number of users, response time requirements, etc.)

Things that the writer should bear in mind

ACKNOWLEDGEMENT
I hereby submit my term paper given to me

Requirements are read more often than they are written. Invest more effort to write documents that are easy to read and understand Readers of requirements come from diverse backgrounds. Don't assume

by my teacher of the subject .I would thank my subject teacher and my friends who have helped me to complete the term paper. I am also highly thankful to all the staff and executives of the esteemed university namely LPU JALANDHAR.

REFERENCES
Bahati Sanga, Assessing and improving the quality of software requirements specification documents, McMaster University, 2003 G. Kotonya, Requirements Engineering, processes and techniques, Wiley, 1997 R.S. Pressman, Software Engineering, a practitioner's approach, Fifth edition, McGrawHill D.M. Berry, Users manuals as a requirements specification, 2003 Zhiming Liu, Object-Oriented Software Development with UML, The United Nations University, July 2002 How to Draw UML 2 Use Case Diagrams, by Scott W. Ambler, available online at http://www.agilemodeling.com/artifa cts/useCaseDiagram.htm