system requirements specification final

45
TABLE OF CONTENTS CHAPTER 1 3 INTRODUCTION 3 1.1 PROJECT OVERVIEW 3 1.2 PURPOSE 4 1.3 OBJECTIVE 4 1.4 SCOPE 4 CHAPTER 2 6 SYSTEM REQUIREMENTS SPECIFICATIONS 6 2.1 INTRODUCTION 6 2.2 PURPOSE 6 2.3 PROBLEM STATEMENT 7 2.4 ASSUMPTIONS 8 2.5 HARDWARE AND SOFTWARE REQUIREMENTS 8 CHAPTER 3 9 UML INTERACTION DIAGRAMS 9 3.1 ACTIVITY DIAGRAMS 9 3.2 SEQUENCE DIAGRAMS 12 CHAPTER 4 14 UML USE CASE MODEL 14 4.1 USER CHARACTERISTICS 14 4.2 USE CASE DIAGRAM 15

Upload: utsav-shah

Post on 12-Nov-2014

1.686 views

Category:

Documents


4 download

TRANSCRIPT

Page 1: System Requirements Specification Final

TABLE OF CONTENTS

CHAPTER 1 3

INTRODUCTION 3

1.1 PROJECT OVERVIEW 3

1.2 PURPOSE 4

1.3 OBJECTIVE 4

1.4 SCOPE 4

CHAPTER 2 6

SYSTEM REQUIREMENTS SPECIFICATIONS 6

2.1 INTRODUCTION 6

2.2 PURPOSE 6

2.3 PROBLEM STATEMENT 7

2.4 ASSUMPTIONS 8

2.5 HARDWARE AND SOFTWARE REQUIREMENTS 8

CHAPTER 3 9

UML INTERACTION DIAGRAMS 9

3.1 ACTIVITY DIAGRAMS 9

3.2 SEQUENCE DIAGRAMS 12

CHAPTER 4 14

UML USE CASE MODEL 14

4.1 USER CHARACTERISTICS 14

4.2 USE CASE DIAGRAM 15

4.3 USE CASE SCENARIOS 16

Page 2: System Requirements Specification Final

CHAPTER 5 23

LOGICAL DATA DESCRIPTION 23

5.1 LOGICAL DESCRIPTION OF DATA 23

5.2 CLASS DIAGRAM FOR AMS 25

5.3 DESCRIPTION ABOUT THE CLASSES 27

CHAPTER 6 30

IMPLEMENTATION ENVIRONMENT 30

6.1 ARCHITECTURE USED 30

6.2 DEPLOYMENT DIAGRAM 31

CHAPTER 7 32

TESTING 32

7.1 INTRODUCTION 32

7.2 SCOPE 32

7.3 TESTING APPROACH 33

7.4 TESTS TO BE PERFORMED 33

7.5 TESTING FOR THE ATTENDANCE MANAGEMENT SYSTEM 33

SAMPLE TEST CASE 34

Page 3: System Requirements Specification Final

CHAPTER 1

INTRODUCTION

1.1 PROJECT OVERVIEW

With the increasing automation and expanding businesses, it is very important that the

information related to our business/institution is maintained in a

better way so that it can be used effectively as and when it is

required. This cannot be done if we do not have a proper system

in place. So, we require a system, which would maintain all the

minute details about the business we are in, which can further be

of great help in the future.

Here, in this case the project deals with creating a system to

develop an Attendance Management System for SDM

Institute for Management Development. This system plans

to automate the attendance process at SDM IMD, in a way

that it will be easy to access the attendance records of any student, be it student

wise, month wise, subject wise or any other such criteria. Another goal of this project

would be to maintain such details over the years instead of just storing them in files

which may be not be that useful and easy to access. The major goal of this system is to

ease and automate the attendance management and generation of timely reports.

The system would have various features like searching students by names, roll

numbers and other such criteria in order to get their attendance information. The

Page 4: System Requirements Specification Final

faculties or the PGDM can also get to know about the attendance of the students for a

particular month, or for a particular subject throughout the term and various other

criteria.

1.2 PURPOSE

The purpose of this AMS for SDM IMD is to automate the process of attendance

recording and report generation in order to consolidate the

attendance for any particular student, subject, or term. It

would also help the faculties to know the attendance of a

particular student for his/her course with just a few clicks

rather than going through various sheets to find out the

attendance records manually.

1.3 OBJECTIVE

The objective of this project is to reduce the manual workload and to make the process

faster and efficient. It would also allow the faculties to view the

attendance and know about the status of various students, as

to how much regular they are for the classes. So in a way, it

also helps the PGDM or the faculties to monitor the attendance of

the students at any time and check out their regularity for the course.

1.4 SCOPE:

The scope of the Attendance Management System can be defined in two ways:

a. Features which are in the scope of the project

This project would contain the following features: Allow to add new students (for 1st yr students)

Assign the chosen subjects to the students (2nd yr students)

Entering attendance for a particular lecture for the students

Page 5: System Requirements Specification Final

Viewing attendance details (reports)

List of students who are absent for more than a specific number of classes.

b. Features which are not in the scope of the project

Automatic graphical representation of attendance for any given period, student,

course, term

Statistical analysis about the attendance

c. Audience: The intended audience for the Attendance Management System at SDM IMD

would be mainly

PGDM Office

Faculties at SDM IMD

d. Organization: The AMS would only be applicable for SDM IMD because of the certain

features, which are customized as per the rules and regulations of SDM IMD.

Page 6: System Requirements Specification Final

CHAPTER 2

SYSTEM REQUIREMENTS SPECIFICATIONS

2.1 INTRODUCTION

The System Requirements Study is documented with an aim to know the

users of the system and the basic activities to be performed by the user.

It tells more about certain constraints, which are to be

implemented in the project, as well as the rules, which it should

follow, in order to merge with the current processes at SDM IMD

so that the whole system does not have to change.

This chapter explains the functional and non-functional

requirements of the system as well as the hardware and software

requirements. The use-case diagrams and scenarios have also been

included in this chapter along with the various other UML diagrams

for the AMS.

2.2 PURPOSE:

Communicates an understanding of users and their interference with the

system.

Helps understanding the limitations, assumptions and

dependencies of the system.

Page 7: System Requirements Specification Final

2.3 PROBLEM STATEMENT

At SDM IMD, currently the attendance is taken manually on a sheet. In

that sheet, the students who are present would sign against

their names, which show that they attended the class. Then

these attendance sheets are filed and kept for further usage like

knowing the total leaves of the student for a course or any such thing.

Now the problem with this process is that to know the attendance results of a

particular student or course, the office needs to look through each and every sheet

and then only they can find out the information that they want. This is very tedious,

time consuming and may not be accurate also.

The new system to be designed should allow the PGDM office to enter the data

about the attendance of a particular course on a specific date for the students who

have opted for the course.The PGDM office can only do entering the attendance

details.

If a particular student has not opted for a course, his name should not be there in

the attendance list when that course is selected for entering the attendance.

The date for entering the attendance cannot be more than 7 days before the

current date.

Once the attendance for a particular course on a given date and a particular session

is entered, it should not allow the user to choose the same combination again, as

the attendance for that combination is already entered.

At any particular point of time, if a student has been absent for 2 or more number

of classes till the current date, a message should be displayed telling that.

Page 8: System Requirements Specification Final

Attendance for students of first and second years would differ slightly because in

the first year, it is assumed that all the students are supposed to undergo all the

courses offered where as in the second year, they are allowed to choose specific

courses according to their specialization.

2.4 ASSUMPTIONS:

One roll number can only be assigned to one student. And the length of the roll

number would not be more or less than 4 digits.

Students, who are newly added to the system, would only be of the 1

need to choose any subjects or specializations for

them.

For second year students, it is assumed that each and

every one has to choose some specific subjects. No limit for how many credits and

subjects they can choose are implemented in this system, as its main task is

attendance management.

It is assumed that all the students for a particular course are present. So only those

who are absent for that particular class have to be unchecked in the system.

2.5 HARDWARE AND SOFTWARE REQUIREMENTS

These details do not comply with the subject Object Oriented Analysis and Design, so

they do not fit into the scope of the document. As a result, they are excluded from this.

Page 9: System Requirements Specification Final

CHAPTER 3

UML INTERACTION DIAGRAMS

3.1 ACTIVITY DIAGRAMS

An activity diagram is used to display the sequence of activities. Activity diagrams show

the workflow from a start point to the finish point detailing the many decision paths

that exist in the progression of events contained in the activity. Activity diagrams are

useful for business modeling where they are used for detailing the processes involved

in business activities.

Page 10: System Requirements Specification Final
Page 11: System Requirements Specification Final
Page 12: System Requirements Specification Final

3.2 SEQUENCE DIAGRAMS

Sequence diagrams are used to represent or model the flow of messages, events and

actions between the objects or components of a system. Time is represented in the

vertical direction showing the sequence of interactions of the header elements, which

are displayed horizontally at the top of the diagram.

Sequence Diagrams are used primarily to design, document and validate the

architecture, interfaces and logic of the system by describing the sequence of actions

that need to be performed to complete a task or scenario. ML sequence diagrams are

useful design tools because they provide a dynamic view of the system behavior,

which can be difficult to extract from static diagrams or specifications.

For the Attendance Management System, we have taken here the sequence diagrams

for three main activities of the system.

Page 13: System Requirements Specification Final
Page 14: System Requirements Specification Final

CHAPTER 4

UML USE CASE MODEL

4.1USER CHARACTERISTICS

Only two types of users would use the Attendance Management System.

PGDM OFFICE:

o It is responsible for the data entry from the

attendance sheets into the system.

o They can modify or update any record

about attendance

o Viewing various reports about students attendance

FACULTY:

o Allowed to view the details about the students attendance

o Take print outs of the various reports as per

their choice

ADMINISTRATOR:

o Adding new students to the system, every year

when the new batch arrives

o Allotting courses to the students who are promoted to the

second year based on their preferences

o Modify details about the students or delete them

Page 15: System Requirements Specification Final

4.2 USE CASE DIAGRAM

Page 16: System Requirements Specification Final

4.3 USE CASE SCENARIOS

4.3.1 LOGIN

Page 17: System Requirements Specification Final

Summary

The PGDM member or faculty navigates to the login page, enters his

or her username and password and selects the option to login to the

system.

Importance Essential

Priority Expected

Use Frequency Always

Direct Actor(s) PGDM member, Faculty, Admin

Pre-requisite(s) The direct actors must have their account in the system

Minimal

guarantee

System sends an error message when the direct actor fails to login to

the system

Success

guarantee

Display the home page to the respective actor who has logged in

successfully.

Main Success

Scenario

1.) Visit login page

2.) Enter username and password

3.) Select the option to login to the system

4.) See personalized home page.

Alternative 2a

Scenario

Extensions

User enters incorrect username and password

1.) The “login” page with empty fields and error message is displayed.

2.) Perform UC-Login: Login to AMS steps 2-4.

Business Rules/

Constraints

1.) The username and password fields are mandatory.

2.) The password should be alphanumeric and the minimum length of

password should be 6 characters.

Page 18: System Requirements Specification Final

4.3.2 ADD NEW STUDENTS

Summary

The administrator can add new students to the system so that

their names feature in the attendance list. New students added

should automatically be added to the group 1st year.

Importance Essential

Priority Expected

Use Frequency Rarely (Once a year)

Direct Actor(s) Administrator

Pre-requisite(s) The user should be logged in.

Minimal

guarantee

The system sends an error message if the roll number already

exists in the system and the user should always be the admin of

the system

Success guaranteeThe system will create the new user and display appropriate

message

Main Success

Scenario

1.) Theadmin will click on the ‘Students’ link

2.) Clicks the link “Add new students” and navigates to the

requested page.

3.) Enters the details about the new student to be added.

4.) Clicks on submit button and the new student is added.

Alternative 3a

Scenario

Extensions

The user roll number already exists.

1.) The same page with empty fields anderror message is

displayed.

2.) Perform UC – ‘Add new students’ with a distinct roll number

Business Rules The user details are mandatory fields.

Page 19: System Requirements Specification Final

4.3.3 MODIFY STUDENT DETAILS

Summary

The administrator can modify the details about the existing

students in the system. These details can be either modifying

the courses, which they have opted for, or other details about

themselves.

Importance Optional

Priority Low

Use Frequency Rarely

Direct Actor(s) Administrator

Pre-requisite(s) The user should be logged in.

Minimal

guarantee

The system sends an error message if some invalid info is

modified and the user should always be the admin of the system

Success guaranteeThe system will modify the details and display appropriate

message

Main Success

Scenario

1.) The admin will click on the ‘Students’ link

2.) Clicks the link “Modify Student Details” and navigates to the

requested page.

3.) Modifiesthe details about the student.

4.) Clicks on submit button and the details would be modified.

Alternative

Scenario

Extensions

The user roll number already exists.

1.) The same page with empty fields and error message is displayed.

2.) Perform UC – ‘Modify students Details’ with a distinct roll

number

Business Rules The user details are mandatory fields.

4.3.4 ALLOT COURSES TO 2ND YEAR STUDENTS

Page 20: System Requirements Specification Final

SummaryDuring the beginning of a new academic year, the PGDM would

allot students, the selected subjects of their choice.

Importance Essential

Priority Expected

Use Frequency Rarely (Once a year)

Direct Actor(s) Administrator

Pre-requisite(s) The user should be logged in.

Minimal

guarantee

The 2nd year students won’t be allotted any subjects and their

selected subjects fields would remain blank

Success guaranteeThe system will create allot the subjects to each students as per

their choice and fill in the details in the database.

Main Success

Scenario

1.) The admin will click on the ‘Students’ link

2.) Clicks the link “Allot Courses” and navigates to the

requested page.

3.) Enters the details about the courses opted by student.

4.) Clicks on submit button and the course details are added for

that student in the system

Alternative

Scenario

Extensions

The students’ subjects are already allotted.

1.) The same page with the allotted fields and a message is

displayed.

2.) Click on update details

3.) Student course details would be updated

Business RulesEach second year student should have the courses assigned

before the data entry of the attendance starts.

4.3.5 ENTERING ATTENDANCE

Page 21: System Requirements Specification Final

Summary After the end of a lecture, the PGDM office has to feed the data in

to the AMS so as to keep a record of the attendance details. It also

helps in proper maintenance of the data and helps in information

retrieval

Importance Essential

Priority Expected

Use Frequency Always

Direct Actor(s) PGDM office member

Pre-requisite(s) The user should be logged in.

Minimal

guarantee

The student is marked present for the lecture in case the update is

not done.

Success guarantee The system will save the attendance details about the students for a

particular lecture on a particular date by the respective faculty and

the given session no.

Main Success

Scenario

1.) The member of the PGDM will click on the ‘Attendance’ link

2.) Clicks the link “Mark Attendance” and navigates to the

requested page.

3.) Enters the details about the attendance opted by student by

selecting the date, the course, faculty and the session no of the

course.

4.) He would then see a list of all the students who have opted for

that particular course along with checkboxes corresponding to

their names.

5.) All students who haven’t attended the lecture, their names are

unchecked and then the details are updated.

6.) Clicks on update button and the attendance details are added for

all the students for the given course, to the system

Alternative

Scenario

The students’ attendance for that particular combination of date,

course, faculty and sessions is already entered in the system.

Page 22: System Requirements Specification Final

Extensions 1.) The same page with blank fields (resettled) is shown

2.) Go back to UC – Entering Attendance. Follow steps 3-6 of the

main case scenario

Business Rules Each second year student should have the courses assigned

before the data entry of the attendance starts.

4.3.6 VIEW REPORTS

Summary

The faculty or the PGDM office member can view various reports

about the students attendance based on various criteria like:

subject wise, term wise, student wise, and month wise.

Importance Optional

Priority Optional

Use Frequency Sometimes

Direct Actor(s) PGDM member, Faculty

Pre-requisite(s)The attendance details have to be added to the system in order to

view the required reports

Minimal

guarantee

System displays a message if no details have been added about the

attendance as per the required report.

Success guaranteeThe details pertaining to the given criteria would be displayed in a

proper table format.

Main Success

Scenario

1.) The administrator clicks on the “Reports” link.

2.) Clicks on the “View Pre defined reports” link and navigates to

the requested page.

3.) Selects the type of report he wants from the given ones

4.) Accordingly, the list of students is displayed along with their

attendance details.

Alternate

Scenario

1.) Clicks on custom reports

2.) Selects the parameters which are for the required criteria

3.) Clicks on ‘Show report’

Page 23: System Requirements Specification Final

4.) The list of students would be shown

Page 24: System Requirements Specification Final

CHAPTER 5

LOGICAL DATA DESCRIPTION

5.1 LOGICAL DESCRIPTION OF DATA

1.) Table Name: Student

Primary key: PgdmNo

Foreign key: CourseID References: Course

Description: This table stores the details of the current students of SDM IMD as well

as the courses, which are opted by them in the final year.

FIELD NAME DATA TYPE SIZE CONSTRAINTS

PgdmNo nvarchar 10 Not Null

StudentName nvarchar 50 Not Null

Year nvarchar 3 Not Null

Batch nvarchar 10 Not Null

CourseID nvarchar 10

2.) Table Name: Course

Primary key: CourseID

Foreign key: FacId References: Faculty

Description:This table contains details about the various courses handled at SDM IMD,

the corresponding faculty for the course and the no of sessions for that course.

Page 25: System Requirements Specification Final

FIELD NAME DATA TYPE SIZE CONSTRAINTS

CourseID nvarchar 10 Not Null

CourseName nvarchar 50 Not Null

Credits Number 3 Not Null

FacID1 nvarchar 10 Not Null

FacID2 nvarchar 10

Term Number 2 Not Null

3.) Table Name: Faculty

Primary key: FacId

Foreign key: None References: NA

Description: It stores the details about the various faculties at SDM IMD, their type as

in they are permanent or visiting as well as the specialization, which they have.

FIELD NAME DATA TYPE SIZE CONSTRAINTS

FacID nvarchar 10 Not Null

FacName nvarchar 50 Not Null

Type nvarchar 15

AreaOfSpec nvarchar 20 Not Null

4.) Table Name: Attendance

Primary key: PgdmNo, FacID, Date, CourseID

Foreign key:PgdmNo, FacID, CourseID

References: Student, Course, and Faculty

Description: This is the main table as it stores the most essential data of the system. It

contains a lot of references to other tables and is largely dependent on data from

other tables. There is no single attribute that is the primary key. In fact, there are four

Page 26: System Requirements Specification Final

attributes, which together form the primary key. These four attributes when

combined, only, can give a unique identity to a row.

FIELD NAME DATA TYPE SIZE CONSTRAINTS

Date datetime - Not Null

FacID nvarchar 10 Not Null

CourseID nvarchar 10 Not Null

SessionNo nvarchar 3 Not Null

PgdmNo nvarchar 10 Not Null

5.2 CLASS DIAGRAM FOR AMS

A class diagram is a type of static structure diagram that describes the structure of a

system by showing the system's classes, their attributes, and

the relationships between the classes. The purpose of a

class diagram is to depict the classes within a model.

Page 27: System Requirements Specification Final
Page 28: System Requirements Specification Final

5.3 DESCRIPTION ABOUT THE CLASSES

COURSE

The course class contains various methods related to course like adding new courses,

modifying the existing ones or deleting some courses

from the system. It also has the method, which

displays all the courses on the page.

The methods for adding, updating or deleting the course have the return

type of Boolean because they would return whether the corresponding methods have

done the work they were allotted to do or were unsuccessful.

The method ‘View Courses by Faculty (FacId)’ would help us in showing the courses

taken by a given faculty. It takes the ‘FacId’ as the parameter and the return type

would be an object of the type ‘Course’.

There are no sub classes or super classes for Course.All the methods are declared as

‘Public’ methods.

STUDENT

The student class contains the details about the students and the courses they have

opted for (for 2nd year students). It contains methods, which allow

showing the list of all the students. It also contains methods,

which allow adding, modifying or deleting the details about the

students.

The method ‘View Students by Course ()’ allows getting the list of students who have

taken a particular course, which helps to generate the list of students during the

attendance entries.

There are no sub classes or super classes for Course. All the methods are declared as

‘Public’ methods.

Page 29: System Requirements Specification Final

ATTENDANCE

The attendance class is the core of the system and does the most

important task of marking the attendance of the students and is also

responsible for major part of the report generation.

The main method of this class is ‘Enter Attendance ()’. It allows

adding the attendance details to the database. This class has to fetch

details from all the other classes and then add these details to the database. It also

contains methods to ‘view attendance details’ as well as to modify them.

For the report generation, this class will contain methods like, ‘Get Attendance by

Course (CourseId)’ or ‘Get Attendance term wise (term No)’, etc. which helps the

retrieval of the data in a more efficient and faster manner.

There are no sub classes or super classes for Course. All the methods are declared as

‘Public’ methods.

FACULTY

This class is just to get and set the details about the faculties by using methods like

‘Add Faculty Details()’ or ‘Modify Faculty Details ()’. It also helps in

displaying the list of faculties in the system by using the ‘View Faculties

()’ method.

For special purposes like viewing some specific faculties based on

the course, it has the function ‘View Faculties by Course (CourseId)’ which will give the

faculties that take a particular course. It also has ‘View Faculties by Area (AreaOfSpec)’

which will give a list of all the faculties belonging to a particular area of specialization.

Page 30: System Requirements Specification Final

CHAPTER 6

IMPLEMENTATION ENVIRONMENT

6.1 ARCHITECTURE USED

The architecture to be used for the development and

implementation of the Attendance management system

would be a 3-tier architecture, keeping in mind, the future

scalability of the system. So it contains three layers as shown

in the deployment diagram.

Presentation layer:Contains the web pages to be

delivered to the browser as and when requested.This layer handles everything to

do with the presentation of your system.

Business layer: It contains the business rules about the Attendance Management

System as well. They neither access data (except through the data layer) nor do

they bother with the display or presentation of this data to the user

Data Layer: Contains the database as well as the data access layer which manages

the transactions of data to and from the database. It also contains the stored

procedures related to the various common tasks of the Attendance management

system

Page 31: System Requirements Specification Final

6.2 DEPLOYMENT DIAGRAM

D

a

t

a

L

a

y

e

r

B

u

s

L

ay

er

Printer

Page 32: System Requirements Specification Final

CHAPTER 7

TESTING

7.1 INTRODUCTION

A software project test plan is a document that describes the objectives, scope,

approach, and focus of a software testing effort. The process of preparing a test plan is

a useful way to think through the efforts needed to validate the acceptability of a

software product. The completed document will help people outside the test group

understand the 'why' and 'how' of product validation

For this project, the majority of the testing would be ‘Black Box Testing’. Various test

cases would be prepared based on the requirements to verify whether they are as per

the needs. These test cases prove to be a support while considering the quality of the

software.

7.2 SCOPE

All the testing will be done according to the program specifications and requirement

study document. Each of the requirements, mentioned in the Requirement analysis is

tested by unit testing, which also indirectly does the requirements validation. We will

be carrying out Unit Testing, Integration testing, and System Testing. All the testing will

be manual and no automated testing tool will be used.

Page 33: System Requirements Specification Final

7.3 TESTING APPROACH

The Flow of the testing is described below.

Unit testing – Individual modules will be tested independently to

ensure that they operate correctly.

System testing – System testing will be done to test whether the system is

working according to the requirement study document.

Integration testing – Integration testing will be done to test whether the system is

working according to the program specifications when the modules are integrated.

7.4 TESTS TO BE PERFORMED:

7.5 TESTING FOR THE ATTENDANCE MANAGEMENT SYSTEM

Screen contains all data elements Range validation

Test for standardization Default value validation

Fonts (size/ type/ style) Computational Test

Alignment Navigational test

Color combination Data type validation

Validation on each data element Test for data update

Test for functions/ procedures used

Page 34: System Requirements Specification Final

Various test cases, as the one shown below would be prepared corresponding to each

of the activities of the system to check whether they are functioning

properly or not. Extensive tests are done on the system and

finally, those tests which fail are recorded in the test cases

records, which would then be rectified.

For each of the use case scenario, there would be a corresponding test case which

would verify and validate the functionality. So for Attendance Management System,

there would be in all around 6 test case which would be required for the complete

functionality of the system

SAMPLE TEST CASE

Test

Case

Id

Test Case

NamePre-condition Process

Expected

ResultActual Result

Pass/Fail

(P/F)

Login_

01

Login

Name

Text Box

User should

be

administrator,

faculty or

PGDM

member

Enter Login

Name and

hit on Tab

key

Login Name

should be

entered in the

Login textbox

and control

should go to

the Password

textbox on

hitting Tab key

Login Name

textbox is filled

with entered

login name and

control goes to

the Password

textbox on hitting

Tab key.

P

Various such test cases would be prepared to check the quality of the system.

7.6 A PROTOTYPE

Page 35: System Requirements Specification Final

Shown below is a prototype of the Attendance Management Systems main page which

shows the core function of the system i.e. the Attendance entry. This is just for the

developers to know how the core functionality should be featuring in the system