Assignment

Name
Department Name
Course Code: Course Name
Instructor Name
Due Date

1
 Table of Contents
Overview of Software Engineering......................................................................................................1
Definition:..................................................................................................................................... 1
Software........................................................................................................................................ 1
Engineering................................................................................................................................... 1
Software engineering....................................................................................................................2
Important of Requirement Analysis.....................................................................................................2
Summary:..................................................................................................................................... 3
Project objectives............................................................................................................................... 3
Scope of Project................................................................................................................................. 4
Requirements..................................................................................................................................... 4
Functional Requirements:.............................................................................................................4
Functional Requirements of our System:.......................................................................................4
Non-Functional Requirements:.....................................................................................................5
Non-Functional Requirements of our System:...............................................................................5
Verifying Requirements......................................................................................................................6
Inspection of our System:..............................................................................................................7
Demonstration of our System:.......................................................................................................7
Testing of our System:..................................................................................................................7
Analysis of our System:.................................................................................................................8
Validating Requirements....................................................................................................................8
Reviewing the Requirement Specification............................................................................................8
Organizational and Completeness.................................................................................................8
Correctness................................................................................................................................... 9
Quality Attributes......................................................................................................................... 9
Traceability.................................................................................................................................. 9
Prototyping the Requirements............................................................................................................10
Use Case Diagram:......................................................................................................................10
Use Case Description:.................................................................................................................10
Reusing the Requirements.................................................................................................................11
Requirements Reusability............................................................................................................11
Why should requirements be reused...........................................................................................12
The Requirements of this system that can be reused:..................................................................12

1
 Functional:............................................................................................................................... 12
Non-Functional:........................................................................................................................12
Conclusion....................................................................................................................................... 13
Main Issues:................................................................................................................................ 13
Recommendation for best practices about Requirement Analysis in Software Engineering
perspectives:................................................................................................................................ 13
A. Recommendations of relevant requirements:...........................................................................13
B. Recommendations for improving the quality of requirements:..................................................14
References:....................................................................................................................................... 15

2
 Overview of Software Engineering
Definition:

 [Frits Bauer]: Software Engineering is the establishment and use of sound engineering

principles, methods, tools, that can be used to produce high quality software that is reliable

and works efficiently on real machines.

 [IEEE]: The application of a systematic, disciplined, quantifiable approach to the

development, operation and maintenance of software; that is application of engineering to

software.

The term is made of two words, Software and Engineering

Software is more than just a program code. A program is an executable code which

serves some computational purpose. Software is considered to be collection of executable

programing code, associated libraries and documentations software, when made for a specific

requirement is called software product.

Analysis Design Implementation

User needs &

Software development process transformations

Engineering on the other hand, is all about developing products, using well defined,

scientific principles and methods.

3
 Software engineering is an engineering branch associated with development of software

product using well-defined scientific principles, methods and procedures. The outcome of

software engineering is an efficient and reliable software product.

Important of Requirement Analysis

needs of the client. Collaborating with the clients and interpreting their needs in a language that

stakeholders understand is the prime purpose of software requirement analysis. This not only

helps development teams to produce robust software but also helps to implement changes by

referring the documentation.

It has been determined that one of the primary reasons why software projects fail is

because the requirements of the project were not captured properly. Current software

applications often operate over multiple platforms and across many locations around the globe.

4
Often during the project lifecycle, the demands keep varying and this can also have an impact in

eliciting proper requirements.

Requirement analysis covers those tasks to determine the needs of a proposed software

solution or product, often involving requirements of various stakeholders associated with the

solution. Requirement analysis is a key component in the software development lifecycle and is

usually the initial step before the project commences.

Requirement analysis is very expensive, requiring huge investments in scarce resources,

systems and associated processes.

Summary:
For the success of a project, it is utmost important to analyze project requirements when

they are gathered as well as throughout the lifecycle of the project. Software Requirements

analysis helps to keep the requirements in line with the need of the business. A good project

requirements analysis process will render a software application that caters to the objectives of

the business set forth.

Project objectives

 The main goal of our software is to monitor the progress of students and alert us

on students who are progressing not well.

 It makes easier to check the students with low CGPA for several semesters.

 Through this system, we can add students, add course, view CGPA, progress,

student who takes less courses and student report, get alert for the students who

are not progressing well.

5
 Scope of Project

Computer has become a necessary part of our life. Every business is a lying on computer

now a days as all have more their management system to computer applications due to its fast

processing and record. For checking or monitoring the progress of students. I will create a

desktop application for this. In this system, admin will add the students and courses, view CGPA

and reports of students, view their progress of student for several semesters and also get alert for

the students who are not progressing well, has low CGPA for several semesters and take less

courses.

Requirements
The software requirements are description of features and functionalities of the

target system. Requirements convey the expectations of users from the software

product.

Functional Requirements:

Functional requirements are the major requirements that are to be considered while

developing a system where it defines some of the dos and don’ts in a system. Also, they are

defined to make sure that the application works as intended. Besides, the functional requirements

of software allow individuals to capture the required intended actions for the system. Because of

such reasons, identifying functional requirements plays a vital role in software engineering.

Functional Requirements of our System:

No. Initial Requirements

1 Admin shall register himself.

6
 3 Admin shall forget password incase if he forgets his password.
4 Admin shall add Students
5 Admin shall add course.
6 Admin shall generate reports
7 Admin shall view progress
8 Admin shall view students who take less courses
9 Admin shall view CGPA
10 Admin shall get alert about students who are at risk

Non-Functional Requirements:

Rather than impacting the functionality of an application, Non-functional requirements define

system behavior, features, and general characteristics that affect the user’s experience. Here, non-

functional requirements specify how the system should carry out a certain task. It generally

focuses on the user’s expectations and product properties. So, even if functional requirements are

fulfilled, it is also necessary to ensure that the non-functional requirements are fulfilled as well to

help in optimizing the quality of the product.

Non-Functional Requirements of our System:

No Requirements
1 Usability:

The user should learn how to use system at most 3 hours

System should be closed for 24 hours per week for maintenance.

System should print error if any module not working and automatic move to home

screen.
4 Fault tolerance:

7
 System should automatically disable module in which error detected and maintain the

working flow of other modules.

System should be recoverable within 24 hours of major failure.

System should create duplicate copy of database with only have the same record but

that is not used in any function.

System should save all record in encrypt form.

System should have different designed interfaces for different modules means

different windows for student, courses and reports.

Verifying Requirements
The four fundamental methods of requirements verification are

 Inspection

 Demonstration

 Test

 Analysis

Inspection is the nondestructive examination of a product or system using one or more of

the five senses (visual, auditory, olfactory, tactile, taste).  It may include simple physical

manipulation and measurements.

Inspection of our System:

8
  Visually examine the software for screens that were requested, check for the fields

needed for data entry, verify that the necessary buttons exist for initiating required functionality,

etc.

Demonstration is the manipulation of the product or system as it is intended to be used

to verify that the results are as planned or expected.

Demonstration of our System:

Enter all required fields on a screen and select the button to return a specific report. 

Ensure that the report is returned with the type of data needed.

Test is the verification of a product or system using a controlled and predefined series of

inputs, data, or stimuli to ensure that the product or system will produce a very specific and

predefined output as specified by the requirements.

Testing of our System:

Admin login into the system. Enter the Students details, Courses, power steering, and

select the generate report for generating the report of every students. View CGPA to check

progress of students and get alerts for the students who are not progressing well and who take

less courses.

Analysis is the verification of a product or system using models, calculations and testing

equipment.  Analysis allows someone to make predictive statements about the typical

performance of a product or system based on the confirmed test results of a sample set or by

combining the outcome of individual tests to conclude something new about the product or

system.  It is often used to predict the breaking point or failure of a product or system by using

nondestructive tests to extrapolate the failure point.

Analysis of our System:

9
 Complete a series of tests in which a specified number of students and courses are added

at the same time.  Measure the response of the system to ensure that the report function generates

report within the time specified. Record the results to capture system degradation. If we are

adding the students detail the system gives us the progress.

Validating Requirements
Validation assesses whether a product actually satisfies the customer needs (doing the right

thing).

We validate that:

 The requirements correctly describe the intended system capabilities and characteristics

that satisfies the various stakeholders’ needs.

 The software requirements are correctly derived from the system requirements.

 The requirements are complete and of high quality.

 All requirements representations are consistent with each other.

 The requirements provide an adequate basis to proceed with design and construction.

 Our system requirements fulfil all the basic needs of customer.

Reviewing the Requirement Specification

Organizational and Completeness

 All requirements are complete and correct because one requirement depend on another.

 All requirements are consistent and have appropriate level of detail.

 The requirements provide an adequate basis for design.

 All external hardware, software, and communication interfaces defined.

10
Correctness

 No requirements are conflict with or duplicate with other requirements.

 Requirements are written in clear, concise, unambiguous language.

 All requirements are verifying by testing, demonstration, review, or analysis.

 Each of the requirement is free from content and grammatical errors.

Quality Attributes

 All performance objectives are properly specified.

 All security and safety considerations are properly specified.

Traceability

 All requirements are uniquely and correctly identified.

 Each software functional requirements are traceable to a higher-level requirement.

By reading each requirement it is clear that what user wants. It’s not about design or

implementation.

Prototyping the Requirements

Use Case Diagram:

11
Use Case Description:

In this scenario, the only main module is generating report to monitor the progress of students.

Because this system is specific not general so we will only write one use case description of the

overall system.

Number UC-ID: 1
Name Student Progress
Summary Admin can add students and courses, and generate report of students to

monitor the progress of students and get alerts on students who are not

performing well.
Priority High
Pre-condition User should authorize and login to the system

12
 Post-condition System shows the progress of students
Primary Actor Admin
Secondary Actor Database
Trigger By clicking
Main Scenario Steps Actions

1 Admin adds the student details

2 Admin adds the course details

3 Admin generates the report of students

4 Admin views the CGPA and the students who takes less courses

5 Admin get alert on the students who are at risk

Reusing the Requirements

Requirements Reusability

Requirements reusability is the process of reusing requirements that have already been

authored and implemented before in previous projects. This technique is used by requirements

engineers to ensure that maximum productivity and consistency are achieved throughout the

product development lifecycle. When it comes to industry-specific compliance and standards, the

information gathered and used, is in most cases, exactly the same. Since this phase requires a

significant amount of time and effort, reusability makes perfect sense as the idea is to reduce

time and effort and achieve consistency.

Why should requirements be reused?

Reusing requirements is a process to save time and effort, but its major benefit comes in

the form of requirement standardization as reusing requirements helps create a repository of

previously implemented and tested requirements. Reuse also assists in creating an improved user

13
experience and better consistency in the project development process. It gives companies a

competitive advantage as the final requirements documents is standardized, and there is a

reduced chance of forgetting the core features and standards required for the end product. 

The Requirements of this system that can be reused:

Functional:

 Login in any management system

 Add student and course in any Learning Management System

 Generating reports in any Learning Management System

Non-Functional:

The requirement that can be reused are:

 Usability

 Maintainability

 Reliability

 Fault tolerance

 Recoverable

 Data Protection

 Security

 Interface

Conclusion

Main Issues:

As the requirements are validated. So there is no issue in the assignment.

14
Recommendation for best practices about Requirement Analysis in Software Engineering

perspectives:

A. Recommendations of relevant requirements:

The recommendations in this group are related to the:

1-Identification of actual requirements:

i.e., recognize text that contains “actual” requirements in contrast to the one that does not

bring valuable information. From the technical perspective, a binary classifier will be used in

combination with some basic Natural Language Processing techniques (to identify actions

expressing a need, such as “must”, “have/has to”, etc.).

2. Identification of similar requirements:

For this purpose, different approaches will be investigated. The first one is based on

content-based recommenders that, by taking into account the requirements and current project

metadata, will be able to recommend requirements. The second approach is based on NLP

techniques (such as tokenization, stemming, and stop words removal) that represent each

requirement using a Vector Space Model (VSM) i.e., the text of a requirement is transformed

into a vector in a multi-dimensional space, where each dimension of the space corresponds to a

term. Therefore, we can compute the similarity among two requirements using measures like

Cosine, Dice or Jaccard

3. Identification of related requirements:

Here, content-based (based on semantic and text-based similarities) and collaborative

recommendation approaches (based on context information) will be used taking into account the

available requirement metadata. Another approach is based on Topic Modelling, which can be

used to associate a label (i.e., a topic) to a requirement or a subset of them, and then cluster the

15
requirements in groups of related ones. The clustering can be done at different level of

granularities (e.g., a hierarchy of topics), achieving different levels of relatedness. The previous

identification task can be improved by the use of: a) domain ontologies, especially to identify

synonyms that are domain-specific, and b) semantic models, to specify how requirements are

semantically related among each other.

B. Recommendations for improving the quality of requirements:

In this case, the recommendations are related to:

1.Measure the quality of requirements to identify bad quality requirements:

A set of rules reflecting quality properties will be identified from existing related work.

These rules can then be used against requirements to check their quality, compounding them to

calculate a quality score.

2. Tips for improving the quality of requirements:

The goal of these tips will be related to reducing ambiguity and improving completeness

and adherence to templates. Some examples of tips would be changing some wording (to

standardize the vocabulary or reduce the ambiguity of requirements) or adding missing

information. Simple word lists can be used to identify weak words (e.g., terms that are

considered ambiguous, such as “sometimes” or “usually”) and thesauruses can be used to

identify alternative terms.

References:

 https://youtu.be/ITlyBV4ttts

 https://reqtest.com/requirements-blog/requirements-analysis/

 https://www.outsource2india.com/software/RequirementAnalysis.asp

 https://youtu.be/zHe4VgW080k

16
 https://www.cs.toronto.edu/~sme/CSC340F/2005/assignments/inspections/reqts_checklis

t.pdf

 Hofmann, H., Lehner, F. (2001). Requirements engineering as a success factor in

software projects. IEEE Software, 18(4). pp.58–66

 Johann, T., Maalej, W. (2015): Democratic mass participation of users in Requirements

Engineering.

 Davis, A.M. (2003): The art of requirements triage.

 Sikora, E., Tenbergen, B., Pohl, K. (2011): Requirements Engineering for Embedded

Systems: An Investigation of Industry Needs.

 Méndez, D., Wagner, S. IST (2015).: Naming the pain in requirements engineering: A

design for a global family of surveys and first results from Germany.

 Mobasher, B., Cleland-Huang, J. (2011): Recommender systems in requirements

engineering. Ai Magazine, 32(3), pp. 81–89

 Hamza, M., Walker, R.J. RAISE (2015): Recommending Features and Feature

Relationships from Requirements Documents for Software Product Lines.

 System Requirements Specification (SyRS) 2.0: The Structure-Behavior Coalescence

Approach

17