ONLNE LIBRARY MANAGEMENT

VISION DOCUMENT
PROBLEM STATEMENT:

In the current working scenario there are many problems that we come across. Some of
them are listed below:-

 Student cannot check the availability of a book from a distant place.

 No aspect of notification and reminders of returning book is not available.

 No back up can be maintained as the data is large and duplication of data

consumes lot of time.

 Analysis on data and access to database is tedious.

 Inability to obtain the status of book rapidly.

 Modify the details of students / books is a large process and is prone to errors.

 It is very difficult to search a particular entry as all book registers are looked
which requires very large work force and is a tedious and cumbersome process.

 No provision for reservation of books and if it is there, it is difficult to maintain

manually.

 Card maintenance causes problem of being lost or tampered and details of

students are searched up from different registers which waste a lot of time.

 Manual allotment of book id causes problem as entry has to be made in each

register.
  It is complex system to understand and require specialized training to work upon
it.

The purpose of the system is to develop a mechanism which reduces the workload on the
librarian, makes the task of using the library easier for the student and results in a better
organization of the library resources. The important features of the system are:

1. The system can support large volumes of books and student data.
2. The staff adds the new student record in its student information database where the
student is allowed to issue up to a maximum of 3 books at a time.
3. The student can reserve the books he wants. If the book is reserved by no other student
can issue the book. The reservation validity will be 2 days after which the reservation will
be cancelled.
4. A student cannot reserve the book already issued to him until he returns it.
5. The system generates the amount of fine as decided by the library management. Return
date is automatically generated. If the book is not returned before the return date arrives
then fine is automatically calculated and the student is bounded to pay the fine amount.
6. Student can search for the book, searching can be done according to title, Author or by
ISBN number.
7. Separate book addition procedures, book issuing procedures and book return
procedures are implemented.
8. Report generation on the basis of various criterions such as listing of books under
different fields such as Author name, ISBN number or the list of currently issued books.
9. Online reading facility to students ie various ebooks present in the library can be read
online.

STAKEHOLDERS AND USER DESCRIPTION:

Name Represents Role

 Librarian This system evolved around the The information needed by the
need of the librarian. librarian is vital. They have
reasonably good computer skills.
The librarian can use the system to
update the database of books,
users, etc.

Employees of the Library The nurses use the system to

They may not have adequate
monitor the books, users, etc.
computer skills.
Users
The user needs to be comfortable
The users use the system to and safe to use the system.
update their accounts, reserve
the books, issue the books, etc.

User Characteristics:

Every user should be comfortable of working with computer and should know how to use the
internet . He must have basic knowledge of English too. Basic knowledge about books is also
necessary.

PRODUCT FEATURES:

The features that are available to the Librarian are:

 A librarian can issue a book to the student

 Can view The different categories of books available in the Library
 Can view the List of books available in each category
 Can take the book returned from  students
 Add books and their information of the books to the database
 Edit the information of the existing books.
 Can check the report of the issued Books.
 Can access all the accounts of the students.
 Can check the fine dues list of the library.

The features available to the Students are:

  Can view The different categories of books available in the Library
 Can view the List of books available in each category
 Can own an account in the library
 Can view the books issued to him
 Can put a request for a new  book
 Can view the history of books issued to him previously
 Can search for a particular book
 Can reserve a book from a remote location and then take it from library manually.

GLOSSARY

 Item: Item refer to any book /Journal/Magazine/Reports that can be issued or not
depending on type of item.
 User: User refers to the persons using the software (Library management
system).It includes System Administrator, Librarian, Student, and Faculty.
 Administrator: Administrator of the system manages the whole system.
 Librarian: A librarian is an information professional working in college library.
 Faculty: A faculty is a teacher in a college teaching one subject area, or a number of related
subject areas.
 Student: It refers to division in college studying different subjects in different department of
college.

Supplementary Requirements:

 Performance Requirements:
The proposed system that we are going to develop will be used as a management system for libraries in
different colleges. Therefore, it is expected that the system would perform all the functions properly.

 Security Requirements:
We are going to develop a secured database for the library. There are different categories of users
namely staff, administrator, students etc. Depending upon the category of user the access rights are
decided. It means if the user is an administrator then he can be able to modify the data, delete, append
etc. All other users other than library staff only have the rights to retrieve the information about
database.

Design Constraints:
The system must be designed to allow web usability. That is, the system must be designed in
such a way that will be easy to use and visible on most of the browsers.

 GUI is only in English.

 Login and password is used for identification of user and there is no facility for guest.
 This system is working for internet so a net connection is mandatory for accessing it.

USE CASE MODEL:

 View book category

Manage reservation

STUDENT Search ebooks

FACULTY

Login

Search book Return books

Feedback

ADMIN Issued book status

STAFF

Login

Book record maintenance

Place notification Issue books

Add/remove staff

Manage student record

Fine calculation

Manage books
 USE CASE: LOGIN

Brief Description:

This use case describes how a user logs into the System. The use case takes in the user name and
password to logon and checks for its validity.

Flow of events:

NORMAL FLOW:

step Actor Description Condition Location

1. Administrator/Staff/User System generate login page which ---------- -----------

request user enter his/her name and
password.

2. Administrator/Staff/User The user enters Login id and password ---------- -----------

3. Administrator/Staff/User The system validates the entered Invalid Alternate

name and password and logs the userid/passwor flow

actor into the system. d

4. Administrator/Staff/User System generates required page ---------- ------------

listing all the available operations.

5. Administrator/Staff/User Use Case Ends. ----------- ------------

ALTERNATE FLOW:

step Actor Description Condition Location

1. Administrator/Staff/User The user enters an invalid Login Id and --------- -----------

password. The System displays an error
 message.

2. Administrator/Staff/User System request to re-enter user ID and ----------- ------------

password. The actor can choose to either
return to the main flow or cancel the
login, at which point the use case ends.

Precondition: User needs a valid user name and password to logon to the system.

Post condition: If the use case was successful, the actor is logged into the system.

Actor: Administrator/Staff/User

Special Requirements: The ID and password should be provided to the Administrator/Staff/User for
login purposes.

USE CASE: MAINTAIN BOOKS

Brief Description:

This use case maintains the information of the books and the book Ids. It adds, deletes and updates
books/book id information
 <<include>>

Add Books

<<include>>

<<include>>
Manage Books
Update Books

delete books

Flow of Events:

NORMAL FLOW:

step Actor Description Condition Location

1. Staff System prompts the staff member to select the desired -------- --------
activity

2. Staff If the activity selected is ADD, the Add Book/Book Id Add new s-1
information Book/Book Id

Sub flow is performed. information

3. Staff If the activity selected is DELETE, the Delete Book/Book Delete s-2
Id information Book/Book Id

Sub flow is performed. information

4. Staff If the activity selected is UPDATE, the update Update s-3

Book/Book Id information Book/Book Id

Sub flow is performed. information

5. Staff If the activity selected is Logout --------- --------

 Use case ends.

SUB FLOW S-1

Step Actor Description Condition Location

1. Staff System generates Add Book/Book ID page, which request --------- ---------
that the Staff to enter the desired information.

2. Staff If the Staff enters information about the book name and Invalid ALT-1
clicks OK button then System adds the new book to the Information

Database of books

3. Staff If the Administrator enter information about the book --------- ----------
and clicks ok button then System Add

New Book to Database of book

4. Staff Staff Wants to Add more books/book ids then go to Step1 ---------- ----------
Or Use case ends

ALTERNATE FLOW ALT-1

Step Actor Description Condition Location

1. Staff If in the main flow , the staff enter an invalid information, the --------- --------
system displays an error message

2. Staff System request to re-enter Correct information .The Staff can ---------- --------
choose to either return to the main flow or cancel, at which
point use case ends.

SUB FLOW S-2

 Step Actor Description Condition Location

1. Staff System generates Delete book/book Id page, which request --------- ---------
that the Staff to enter book id to delete book id information
or the book name to delete book information.

2. Staff If Staff enters book id & click delete the System Deletes --------- ----------
Book Id info. from Database

3. Staff If Staff enters book name & click delete the System Deletes ---------- ----------
Book info. from Database

4. Staff Staff Wants to Delete more. Books/Book ids info then go to ---------- ----------
Step1Or Use case ends.

SUB FLOW S-3

Step Actor Description Condition Location

1. Staff System generates Update Book page, which request that ---------- ----------
the Staff to enter book id to update Book Id information or
the Book Name to update Book information.

2. Staff If the Staff enters book id information and clicks on update Invalid ALT-2
button, System updates Book Id information to Database Information

of books

3. Staff If the Staff enters book information and clicks on update ------------ ---------
button, System updates Book information to Database of
boo

4. Staff Staff Wants to update more books/book ids then go to --------- --------
Step1 Or Use case ends
ALTERNATE FLOW ALT 2

Step Actor Description Condition Location

1. Staff If in the main flow , the Staff enter an invalid information, -------- -------
the system display an error message

2. Staff System request to re-enter Correct information -------- --------

The Staff can choose to either return to the main flow or

cancel, at which point use case ends.

Precondition: User needs a valid user name and password to logon to the system.

Post condition: If the use case was successful, the Staff maintains books/book id information (i.e.
add, delete, update).

Actor: Staff

Special Requirements: The details about the books such as the book id, book name, subject
department, edition etc. must be known.

USE CASE: VIEW BOOK INFO

Brief Description

This use case facilitates the members to view information about the books available in the library.

Flow of Events

NORMAL FLOW
 Step Actor Description Condition Location

1. Administrator/Staff/User System generates View books page, ------ ------

which request that the
administrator/user to enter book name
to view book information or the book id
to view book id information.

2. Administrator/Staff/User If the Administrator enters the book Invalid ALT-1

name & click view button then the information

System Displays book details.

3. Administrator/Staff/User If the Administrator enters the book id ------- --------

& click view button then the System

Displays book id details.

4. Administrator/Staff/User Administrator Wants to view more -------- --------

books/book ids then go to Step1

Or Use case ends

ALTERNATE FLOW ALT 1

Step Actor Description Condition Location

1. Administrator/Staff/User If in the main flow , the administrator ------- --------

enter an invalid information, the system
display an error message

2. Administrator/Staff/User System request to re-enter Correct ------- --------

information. The Administrator can
choose to either return to the main flow
 or cancel, at which point use case ends.

Precondition: None

Post condition: If the use case was successful, the book/book id details are displayed.

Actor: Administrator/Staff/User

Special Requirements: The name of the book or the book id must be known

USE CASE: ISSUE RECORDS

Brief Description

This use case maintains the information of the books issued to various members. It adds, deletes
and updates issued books information
 add issue record
<<include>>

<<include>>

delete issue record

<<include>>

Issue record
<<include>>

update issue record

view issue record

Flow of Events

NORMAL FLOW

Step Actor Description Condition Location

1 Staff System prompts the Staff to select the desired activity ------- ------

2 Staff If the activity selected is ADD, the Add issue record Add issue S-1
record
Sub flow is performed.

3 Staff If the activity selected is DELETE, the Delete issue Delete issue s-2
record Sub flow is performed record

4 Staff If the activity selected is UPDATE, the update issue Update issue s-3
 record Sub flow is performed. record

5. Staff If the activity selected is VIEW, the view issue record View issue s-4
record
Sub flow is performed.

6. Staff If the activity selected is LOGOUT Use case ends ------- --------

SUB FLOW S-1

Step Actor Description Condition Location

1. Staff System generates Add issue record page, which requests ------ ------
the Staff to enter user id , book id, date of issue, date of
return etc.

2. Staff Staff enters above information Invalid ALT 1

information

3. Staff Click add button -------- --------

4. Staff System Add New issue record to the database -------- ---------

5. Staff Staff Wants to Add more issue records then go to Step1 ------- ----------

Or Use case ends

ALTERNATE FLOW ALT 1

Step Actor Description Condition Location

1. Staff If in the main flow , the Staff enter an invalid information, -------- -------
the system display an error message

2. Staff System request to re-enter Correct information -------- --------

The Staff can choose to either return to the main flow or

 cancel, at which point use case ends.

SUB FLOW S-2

Step Actor Description Condition Location

1. Staff System generates Delete issue record page, which ------- --------
request that the Staff to enter user id and due return

2. Staff Staff enter above information & click delete ------- --------

3. Staff System Delete. Issue record. from Database -------- --------

4. Staff Staff Wants to Delete issue records then go to Step1 -------- --------

Or Use case ends

SUB FLOW S-3

Step Actor Description Condition Location

1. Staff System generates Update issue record page, which ------- --------
request that the Staff to enter user id and due return
date

2. Staff Staff enters the required information Invalid ALT-2

information

3. Staff Click update button -------- --------

4. Staff System updates issue record to Database -------- --------

5. Staff Staff Wants to update more issue records then go to

Step1 Or Use case ends
ALTERNATE FLOW ALT 2

Step Actor Description Condition Location

1 Staff If in the main flow , the Staff enter an invalid -------- ------
information, the system display an error message

2 Staff System request to re-enter Correct information --------- -------

The Staff can choose to either return to the main flow

or cancel, at which point use case ends.

SUB FLOW S-4

Step Actor Description Condition Location

1 Staff System generates View issue record page, which -------- --------
request that the Staff to enter user id and due return
date

2 Staff Staff enter above information Invalid ALT-3

information

3 Staff Click view button -------- --------

4 Staff The system displays the issue record details. -------- --------

5. Staff Staff Wants to view more issue records then go to -------- --------
Step1

Or Use case ends

ALTERNATE FLOW ALT 3

Step Actor Description Condition Location

1 Staff If in the main flow , the Staff enter an invalid -------- --------
 information, the system display an error message

2 Staff System request to re-enter Correct information -------- --------

The Staff can choose to either return to the main flow

or cancel, at which point use case ends.

Precondition: Staff needs a valid user name and password to logon to the system.

Post condition: If the use case was successful, the Staff maintains and views the records of books
issued to the various members (i.e. add, delete, update, and view).

Actor: Staff

Special Requirements: The details such as the user id, book id, date of issue, return date etc. must
be known.

USE CASE: STAFF MAINTAINENCE

Brief Description

This use case maintains the information of the staff that works in the library. The chief library officer
who is the administrator can add a new staff to the system and can also delete an existing staff.
 <<include>>

Add Staff
<<include>>

Manage Staff

Remove Staff

Flow of Events

NORMAL FLOW

Step Actor Description Condition Location

1 Admin System generates manage staff page --------- ------

2 Admin Add staff --------- S1

3 Admin Remove Staff --------- S2

SUBFLOW S1:

Step Actor Description Condition Location

1 Admin System generates add staff page --------- ------

2 Admin Admin feeds the new staff entry. Invalid entry ALT
 3 Staff record gets entered in the staff Table. Use case ends ---------

ALTERNATE FLOW:

Step Actor Description Condition Location

1 Admin In main flow if required mandatory fields are not fulfilled --------- ------
it display error message

2 Admin System requests to enter user information/ can cancel in ---------- ------
that case use case ends

SUBFLOW S2:

Step Actor Description Condition Location

1 Admin System generates remove staff page --------- ------

2 Admin Feeds the Staff ID of the staff to be removed. ---------- ------

3 Admin Staff data gets removed. Use case ends.

Precondition: Administrator should be logged in.

Post condition: If the use case was successful, the refreshed list of staff is displayed.

Actor: Administrator.

USE CASE : STUDENT RECORD MAINTAINENCE

Brief Description

This use case maintains the information of the student that use the library.
 <<include>>
Add Student

<<include>>

<<include>> Remove Student

Manage Student Record

Update Student Record

Flow of Events

NORMAL FLOW

Step Actor Description Condition Location

1 Admin/Staff System opens the page of the student record. --------- ------

2 Admin/Staff Add a new student record. ---------- S1

3 Admin/Staff Delete an existing student record ----------- S2

4 Admin/Staff Update an existing student record ----------- S3

SUBFLOW 1

Step Actor Description Condition Location

1 Admin/Staff System opens the page of the student entry --------- ------

2 Admin/Staff Actor fills in the form. Invalid Entry ALT1

3 Admin/Staff System updates the database. ----------- ------

4 Asks for more student entry ----------- ------

Use case ends

ALT1

Step Actor Description Condition Location

1 Admin/Staff System gives an error message. --------- ------

System prompts for a valid entry.

SUBFLOW 2

Step Actor Description Condition Location

1 Admin/Staff System opens the page of the student record --------- ------
deletion

2 Admin/Staff Actor gives the Student ID for deletion Invalid Entry ALT1

3 Admin/Staff System deletes from database. ----------- ------

4 Admin/Staff Asks for more deletion. ----------- ------

 Use case ends.

ALT1

Step Actor Description Condition Location

1 Admin/Staff System gives an error message. --------- ------

System prompts for a valid entry.

SUBFLOW 3

Step Actor Description Condition Location

1 Admin/Staff System opens the page of the student record --------- ------
updation.

2 Admin/Staff Actor gives the Student ID for update. Invalid Entry ALT1

3 Admin/Staff System updates the database. ----------- ------

4 Admin/Staff Asks for more updation. ----------- ------

Use case ends.

ALT1

Step Actor Description Condition Location

1 Admin/Staff System gives an error message. --------- ------

 System prompts for a valid entry.

Precondition: Administrator should be logged in.

Post condition: If the use case is successful, the refreshed list of student is displayed.

Actor: Administrator.

USE CASE: FEEDBACK

Brief Description

This use case maintains the feedback of the student that use the library to the administrator.

Flow of Events

NORMAL FLOW

Step Actor Description Condition Location

1 User Opens the page for feedback. --------- ------

2 User Feeds in the feedback. --------- ------

3 Admin Can read the feedback. ----------- ------

Precondition: Administrator should be logged in.

Post condition: If the use case was successful, the administrator gets to know the feedback of the
users of the library..

Actor: Administrator, User.

USE CASE: NOTIFICATION

Brief Description

This use case maintains the notifications published by the administrator.

Flow of Events

NORMAL FLOW

Step Actor Description Condition Location

1 Admin System opens the page for placing notification --------- ------

2 Admin Writes notification and publishes it. --------- ------

3 Admin View previous notification. ----------- ------

Use case ends.

Precondition: Administrator should be logged in.

Post condition: If the use case was successful, the administrator can post notifications on the
website.

Actor: Administrator.

USE CASE: BOOK RESERVATION

Brief Description:

This notification tells us about how a book is reserved by a user.

<<include>>

Make Reservation
<<include>>

Reservation

Cancel Reservation

NORMAL FLOW:

Step Actor Description Condition Location

1 User System generates the page for reserving the ---------- ----------
books.

2 User Can make reservations. ---------- Sub 1

3 User Cancellation of reservation. ---------- Sub 2

SUB FLOW 1:

Step Actor Description Condition Location

1 User System checks if the book is available. Not available Alt 1

2 User System checks the database. Already Alt 2

reserved

3 User Reserves in the database. ---------- ----------

Use case ends.

ALTERNATE FLOW ALT 1:

Step Actor Description Condition Location

1 User System prompt for non availability of books. ---------- ----------

2 User System request for another book & redirects to ---------- ----------
the home page.

Use case ends.

ALTERNATE FLOW 2:

Step Actor Description Condition Location

1 User System gives an error message of already ---------- ----------

reserved books.

2 User System request for another book & redirects to ---------- ----------
home page.

SUB FLOW 2:

Step Actor Description Condition Location

 1 User System opens the cancellation page. ---------- ----------

2 User System takes the reserve ID/book ID of the Invalid id Alt 1

books to be cancelled.

3 User System removes the entry from the database ---------- ----------

Use case ends.

ALT ERNATE FLOW 1:

Step Actor Description Condition Location

1 User System prompts an error message. ---------- ----------

2 User System prompts for an valid id or redirects to ---------- ----------

home.

Precondition: User should be logged in.

Post condition: If the use case was successful, the user reserves the book and collect it when he
goes to the library within a given timeframe.

Actor: User

USE CASE: FINE

Brief Description: This use case maintains the fine paid by student due to the late submission of book.

FLOW OF EVENTS:

NORMAL FLOW:

Step Actor Description Condition Location

1 Staff System opens the page for returning books. ---------- ----------

2 Staff Actor enters the book id Invalid entry Alt 1

3 Staff System calculates the fine and display it. ---------- ----------

4 Staff System asks for more entry. ---------- ----------

Use case ends.

ALTERNATE FLOW 1:

Step Actor Description Condition Location

1 Staff System displays an error message & request for

the correct entry

Precondition: Staff member should be logged in.

Post condition: If the use case was successful, the staff will be able to impose fine on the late book
returns.

Actor: Staff.
Conceptual Level Sequence Diagram
6.2.4 Conceptual Level Activity Diagram
 Go to web page

Select option

Library books Staff

Ebook
Student View new
notification

Search string
for Ebook

Enter username & System show latest

Enter search
password notification
string for Ebook

no if valid ?
system display list of Ebook
with the entered string
yes

Perform activity

yes next activity

no

Stakeholder’s request:-

An individual who is materially affected by the outcome of the system. End users are often
thought of as the primary stakeholders, but other stakeholders, such as shareholders and
executive management, among others, also have a stake in the project.
A requirement describes a condition or capability to which a system must conform; it can be
either derived directly from user needs, or stated in a contract, standard, specification, or
other formally imposed document. A desired feature, property, or behavior of a system.

1 General Requirements:-
These requirements describes the system objectives. In our project, the general requirements are
to view & compare results, view performance of required faculty on the basis of results of last 3
years, compare performance of two faculties, view performance of faculty in different class,
compare branch-wise result, view result variation of a batch, view result variation of a student,
calculate aggregate for student, calculate the marks required by student in next exam to obtain
the desired result, compare result of two batches.

2. Expected Requirements:-
These are implicit to software as users consider them to be fundamental requirements which are
accomplished in the software & hence do not express them. For example ease of software
installation, ease of software & user interaction, user friendly software etc.

3. Unexpected Requirements:-
These requirements specify the requirements that are beyond users expectations. These
requirements are not requested by the user but if added to the software they become an additional
feature. In this project the graphical comparison provided for comparison of results is the
unexpected requirement, which is an additional feature.

STORYBOARD:

A Storyboard is a logical and conceptual description of system functionality for a specific

scenario, including the interaction required between the system users and the system. A
Storyboard "tells a specific story". Storyboards can be used to explore, understand and reason
about the behavioral requirements of the system, especially how the users will interact with the
system. Storyboards are meant to make textual scenarios more "real" by using pictorial means to
specify the requirements They are not intended to be a first draft of the user interface, but are
intended to just represent the user's interactions with the system. Various storyboards are already
covered in SRS above.

In our discussion of use case model, we have already discussed all the logical and conceptual
description of each use case, which in turn describes the individual functionality of the system.
 Requirement Management Plan:-
The five levels of maturity for our RMM are: 1) written 2) organized 3)structured 4) traced, and
5) integrated. We will use these categories to partition requirements management practices,
starting at the lowest level (One) and moving up through Level Five.

Actually, there is one other level on the requirements maturity scale: Level Zero -- no
requirements. At Level Zero,they make broad assumptions that they know what to build;and the
time in which the software can be build. Sometimes this gamble works, but more often than not,
a product is released that is missing functionality, has functions that are not needed,
or is of poor quality.

Level One --Written Requirements

The first step up is simply to write the requirements. Once you write requirements, several
benefits become obvious.First, you have a real basis for a contract with your customer. If you
write them well, the requirements can clearly state your understanding of what the customer
wants you to build, and they can read the requirements and agree (or disagree).Second, everyone
on your development team has a basis for doing his or her work. Third, as you staff up the
project, new members, too, will have a source for figuring out what the application or system is
supposed to do. Our project meets this level as we have written all the requirements in a well
organized manner which states all the objectives clearly. The customer is agreed with all
requirements. Also,it helped us a lot while assigning the tasks to the members of the team based
on the different objectives classified. Everyone on our development team has a basis for doing
his or her work.

Level Two -- Organized

At this level an organization deals with things like the quality of the requirements, their format,
their security, where they are stored, and how to keep track of different versions.The goal of a
requirement is to clearly communicate the proposed behavior of the software to a diverse set of
constituents: users, customers and other stakeholders, as well as the development team. A good
set of requirements does this job well; a bad one does not. Good requirements are understandable
by stakeholders who specify them.
Formatting
Requirements must also be formatted effectively. Consistent numbering schemes, headers, fonts,
and a good table of contents make your documents easier to read, understand, and use. We have
used better fonts, headers and classified all the req. uniquely & effectively.

Accessibility, Security, and Version Control

At Level Two, you need a central, well known location for the requirements, one that is
accessible by all users. Limiting the ability to modify requirements to authorized persons only
can help ensure the requirements' integrity.Costs associated with getting to Level Two relate
mostly to training and review.
In our project we have given authentication levels to each user according to the need.
When your requirements are more readable and easier to understand (and more trustworthy), you
will have a better basis for a contract with the customer,the development team will find the
requirements easier to use, and new staff will be able to come up to speed more quickly. Writing
quality requirements is not a simple task. Getting to, and staying at, a given maturity level will
require consistent review of requirements documents and some level of "process enforcement".

Level Three -- Structured

Getting to Level Three involves being more specific about the "types" of requirements you
gather. Are they functional or nonfunctional.Making these distinctions helps you get a better
understanding of the requirements and manage them better.
Getting Your Types Straight
The first issue arises if you do not distinguish among different types of requirements. If your
current requirements specification simply contains a big list of requirements with no indication
of their type, it is likely that the list contains a mix of different types.
Attributes
All requirements are not created equal: Some are more important than others; some are more
stable than others.These are important things to keep track of, and adding attributes for
requirements can help you do so. Attributes include information that supplements the
requirement text and helps you better understand and manage your requirements.Benefits of
getting to Level Three revolve around better understanding and easier management.
In our project we have used well-structured requirements clearly identify different
requirement types, and attributes provide the ability to query and filter groups of requirements.
Better typing of requirements also provides greater assurance that the team has identified all
important requirements. The main cost of getting to Level Three is in planning and maintenance.
Determining appropriate requirement types and attributes is not a trivial task.
Usually this information is captured in a Requirements Management Plan (RMP). Then,
requirements attributes are of little use if they are not kept up-to-date, so there is a maintenance
burden that goes beyond the one for Level Two. There is an increased cost too, because
determining the correct attribute values takes time. Often, when organizations get to Level Three,
they institute the use of a requirements management tool like Rational RequisitePro. This has
large benefits that often outweigh the cost of purchasing, updating, and administering the
software.
Level Four -- Traced
Most systems of any significant complexity will have a hierarchy of requirements. In a systems
engineering environment, this hierarchy starts with system requirements and moves down to
subsystem requirements, program requirements, and element requirements. In the Rational
Unified Process, the hierarchy starts with user needs, proceeds to features, and then goes on to
use cases. The ability to keep track of these relationships is commonly called traceability,and it
entails identifying and documenting the derivation path (upward) and allocation/flowdown path
(downward) of requirements in the hierarchy. Traceability provides the ability to understand how
changes to
one requirement might affect others (impact analysis) and can also help determine if your
requirements are complete (coverage analysis).Usually, an organization at Level Four will
develop an explicit traceability strategy prior to starting a project and then document it in the
requirements management plan. The strategy will define the requirements levels and how they fit
in the hierarchy. In addition, it will lay down some "rules" for requirements relationships.
Level Five -- Integrated
It is often the case that requirements are used up front to get agreement from the customer on
what the software is supposed to do, but then those requirements are not really tied in to the way
the software is developed. This results in stale requirements and software that doesn't meet its
objectives. Reaching Level Five means integrating the requirements management process with
the rest of your software development environment. Software that does what the customer
expects is built to comply with the requirements -- that is, the team's software development
process uses the requirements as a key input. Integrating requirements into your change
management process helps ensure that no changes are made to requirements without review and
approval. A comprehensive, requirements-based software development process as described
here takes significant planning, training, and process enforcement.
Requirements Management Tool Support
Until Level Five, it is theoretically possible to do everything that we have talked about either
"manually" or with general-purpose tools like a word processor and spreadsheet. However,
starting at Level Two, an RM tool can help you be far more efficient and consistent. Table 1
shows how the important features of Rational RequisitePro support key characteristics of the five
RM maturity levels.