Chapter 1: The essential software requirement:

This chapter broadly explains about the importance of software requirements and the difficulties
which arise during its classification. It clearly explains the key terms, various levels and types of
requirements. Some of the types are business requirements, business rule, constraint, quality
attribute, system requirement, user requirement, functional & non-functional requirement.
Software requirement embraces three major levels: functional requirement, business requirement
and user requirement.
Business requirements details about the elicitation and documentation of requirements of
business users and focuses on the business objectives of the organization. In requirement
engineering, business requirements are recorded in vision and scope document.
User requirements documents the tasks and goals of the user. It also includes detailed description
of product characteristics and their attributes which are important to the user. To represent user
requirements use cases, user stories and event-response tables are taken into consideration.
Functional requirements illustrates the behavior of the product which is exhibited under certain
conditions. It describes developers what to implement to enable users accomplish their tasks.
These requirements are documented by business analyst.
It is difficult for the engineering team to analyze the requirements because there are large number
of stakeholders. A stakeholder is a person who has vital interest in the business. Apart from the
three major levels of requirement, another important aspect of requirement engineering is nonfunctional requirement. It specifies the characteristics or the properties which include usability,
availability, security, performance and other quality attributes.
Requirement engineering is addressed into two parts, Requirements Development and
Requirements Management. Requirement development further divided into analysis, elicitation,
specification and validation. All these sub parts of requirement development include activities
like exploring, documenting, evaluating and confirming the requirements.
Elicitation identifies the use cases and involves in discovering requirements like document
analysis, prototyping, interviews and other.
Analysis involve understanding of every single requirement and representing the group of
requirements in different ways. It negotiates the properties and prioritize the quality attributes
based on their importance.
Specification translates user needs into written requirements and diagrams which are suitable for
review and comprehension.
Validation verifies whether the collected requirement information is satisfying business
objectives. It helps in reviewing the requirement document and provides assistance to achieve the
business objectives.

If all the requirements are properly documented from a high-quality requirement process then it
reduces the development work, reduces miscommunication, produces customer satisfaction and
accelerates development process.
In this chapter, I have learned the process of identifying all the requirements such as user
requirements, business requirements and system requirements. I have inculcated in me several
useful terminologies and techniques which helps in understanding requirements that satisfy
business objectives. By understanding requirement development process which involved various
levels, it made me understand that not only requirement gathering is necessary but also
requirement verification and validation is also important to make sure the requirements gathered
are satisfying the business goals.

Chapter 2: Requirements perspective from customers perspective:

This chapter focuses on the requirements from an eye of customer. A customer is subset of
stakeholder. A stakeholder is a person or a group or an organization who actively shows interest
in the project or its process. A customer is a person or an organization who is benefited from the
product.
In general, a good software is an outcome of well executed design which are based on excellent
requirements. Excellent requirements are outcome from successful collaboration between
customer and developer. A customer typically expects business analyst to understand your
business vocabulary, learn about his business objectives and goals, record his requirements in an
appropriate form, provide explanations and recommendations for all the requirement practices,
manage, assess and communicate impacts, maintain an environment with mutual respect, provide
new ideas and requirements for their solutions and finally expects a system which satisfies his
needs and quality.
As a customer, it is important that they provide ample information about their business, provide
time which takes to clarify requirements, to give specific and precise inputs while defining
requirements, to review and evaluate requirements, to communicate properly to the changes in
the requirement and lastly to respect the requirement specification process.
It is very hard to get agreement from all the stakeholders because of barriers such as busy
schedule and reluctance. In general, customers are given confidence that the developers will
work to build the product which satisfies their needs.
To summarize, this chapter deals in understanding the requirements from customers perspective
and provide evidences that record miscommunication between customer business analysts.
In this chapter, I have learned how to think like a customer when it comes to understand their
business requirements. Also, I have analyzed what a customer expects from a business analyst
like understanding their business vocabulary and familiarizing their objectives and goals.

Chapter 3: Good practices for requirements engineering

This chapter briefly describes good practices which are required for requirement development
process. These practices involves elicitation, analysis, specification and validation, each has to
perform these activities in iterative and incremental approach.
In requirement elicitation, one should define the scope and vision of the project which contains
business requirements, identify user classes with their characteristics i.e., identify characteristics
that influence product design, to pick a product champion for every user class i.e., to identify an
individual who can serve as voice of customer for every user class, to work with user
representatives and identify their requirements, figure out system responses and events, conduct
elicitation workshops and interviews, perform analysis of the document which will help to
understand the work done and lastly reexamine and reuse the existing requirements which are
flexible to reuse.
In requirement analysis, requirements are refined to ensure that all the stakeholders understand
the requirements. In analysis, all the high-level requirements are decomposed to appropriate
levels, prototypes and negotiating properties. The primary factor of this phase is to develop
requirements which are sufficient enough in terms of quality and precision. It involves modelling
the application environment which is drawing a context diagram that shows