Types of Project Requirements

In general, requirements can be categorized in three ways: business requirements, solution

requirements and stakeholder requirements.

Business Requirements

Business requirements are the overall needs of the business for making the project happen.
Requirements that fall into this category are more foundational, long-term needs that support the long-
term goals of the organization. Project management offices (PMOs) are usually in charge of making sure
that projects, programs and portfolios are aligned with the strategic goals of an organization.

Solution Requirements

Solution requirements are more product-focused and drill down a little deeper. They can be functional
or non-functional, and they ensure that the end result of the product satisfies both what the product

What are functional requirements in software engineering?

Functional requirements can be most simply defined as:

Something the system must do.If the system does not meet a functional requirement it will fail. This is
because it will not be able to achieve something it must do to operate properly. The functional
requirement concept can also be understood through reviewing the system in terms of inputs and
outputs. Functional requirements specify what the system must do in response to different inputs and
what it must output.

Functional requirements examples

Looking at some functional requirements examples is helpful to understand

what they are. Generally speaking, functional requirements are comprised of
both product features and user requirements.

Some examples of functional requirements include:

 Specifications of what the system must do

 Business rules that must be met

 Steps that the system must take in authentication

 Details of what must be tracked in the system

  The reporting requirements of the system

 Specifics relating to legal or regulatory compliance

 Outlines the levels of user and their authorization

 Details of how transactions must occur

What are non functional requirements in software engineering?

Non functional requirements in software engineering can be explained as:

Requirements that describe how the system works.

Non functional requirements are focused on how the system goes about
delivering a specific function. At first glance they might be seen as less
important than functional requirements but both have a part to play in a
good system. Non functional requirements do not have an impact on the
functionality of the system but they do impact on how it will perform. In
short, non functional requirements are all about system usability. If non
functional requirements are not met, users may become frustrated with how
the system works and go elsewhere. Meeting at least some non functional
requirements is important in a well performing system

Non functional requirements examples

Non functional requirements examples help to better understand what these are. Here are some
examples:

Speed – how fast the system performs certain activities.

Availability – for how much of the time the system is available e.g. does it operate overnight, or every
day of the year, or not.

Capacity – what the limits are of what the system is able to handle.

Reliability – how dependable the system is.

Usability – how easy the system is to use for the customer or end user.

Exploring this concept in greater detail, non functional requirements examples might include:

1. The time taken for a specific page to load.

2. The speed within which certain requests must be processed.

 3. The level of availability the system should have.

4. Which functions can be performed at different times, and when maintenance will be carried out.

5. How many users the system can handle concurrently.

Performance requirements define how well the software system accomplishes certain functions under
specific conditions. Examples include the software's speed of response, throughput, execution time and
storage capacity. The service levels comprising performance requirements are often based on
supporting end-user tasks

Environmental Requirements means all present and future Laws, orders, permits, licenses, approvals,
authorizations and other requirements of any kind applicable to Hazardous Materials.

Requirement Types

Users, System Engineers, and Program Managers will have to develop several different types of
requirements on an acquisition program through its life cycle. These requirements range from very
high-level concept-focused to very specific for a part. The four (4) main types of requirements that you
can expect on a program are:

 Functional Requirements

 Performance Requirements

 System Technical Requirements

 Specifications

Definition: A requirement is a statement that identifies a product or process operational, functional, or

design characteristic or constraint, which is unambiguous, testable or measurable, and necessary for
product or process acceptability. (ISO/IEC 2007)

Functional Requirements

A functional requirement is a task (sometimes called action or activity) that must be accomplished to
provide an operational capability (or satisfy an operational requirement). Some functional
requirements associated with operations and support can be discerned from the needed operational
capability

Functional requirements define what a product must do and its features, functions, and specific
capabilities.

Experience in systems engineering has identified eight generic functions that most systems must
complete over their life cycle: development, manufacturing, verification, deployment, training,
operations, support, and disposal. These are known as the eight primary system functions. Each must
usually be considered in identifying a system’s functional requirements.
Performance Requirements

Performance requirements define the standards that determine a system’s effectiveness,

responsiveness, and scalability. They are frequently classified as non-functional requirements.
Performance requirements concentrate on how well a system operates under different circumstances,
as opposed to functional requirements, which list specific capabilities. This encompasses variables like
Performance criteria and other non-functional requirements are essential to guarantee that a system
fulfills user expectations and performs at its best. They direct implementation and design, highlighting
elements crucial to system stability and user experience.

Performance requirements define how the system should perform.

A performance requirement is generally measured in terms such as quantity, accuracy, coverage,

timeliness, or readiness. The performance requirements for the operational function and sometimes a
few others often correlate well with the statement of the needed operational capability developed by
the Joint Capabilities Integration and Development System (JCIDS) Process. The statement of other
performance requirements usually requires thorough systems engineering.

System Technical Requirements

System technical requirements are the result of both allocated and derived requirements. These types
or requirements are:

 Allocated Requirements: flow directly from the system requirements down to the elements of
the system.

 Derived Requirements: dependent on the design solution (and so are sometimes called design
requirements). They include internal interface constraints between the elements of the
system.

Specifications

A specification is a detailed, exact statement of particulars, especially a statement prescribing

materials, dimensions, and quality of work for something to be built, installed, or manufactured. The
overall purpose of a specification is to provide a basis for obtaining a product or service that will
satisfy a particular need at an economical cost and to invite the maximum reasonable competition. By
definition, a specification sets limits and thereby eliminates or potentially eliminates items outside
the boundaries drawn. A good specification should do four (4) things:

1. Identify minimum requirements.

2. List reproducible test methods to be used in testing for compliance with specifications.

3. Allow for a competitive bid.

4. Provide for an equitable award at the lowest possible cost.

  Business Requirements: articulate an organization’s goals and intended results. Engineers who
don’t understand how they will be implemented frequently dismiss them as “fluffy,” but if
they are stated clearly, they can be reduced to quantifiable claims. Usually, the product owner
or sponsor, the marketing division, or the client defines them in a business case or other
documents. They try to explain the organization’s financial and resource commitment to the
project.

 Stakeholder Requirements: outline the characteristics that must be satisfied in order for the
business requirements to be satisfied. They also express the demands and expectations of the
stakeholders. While performance and reliability as well as a range of other non-functional
needs, may be expected by stakeholders, analysts often concentrate on the functional
components of the needs. Both are essential and serve as stepping stones for defining the
functional and non-functional requirements that the designers and implementers will need to
achieve to produce solutions that live up to the client’s expectations.

What is a use case diagram?

In the Unified Modeling Language (UML), a use case diagram
can summarize the details of your system's users (also known
as actors) and their interactions with the system. To build
one, you'll use a set of specialized symbols and connectors.
An effective use case diagram can help your team discuss
and represent:
 Scenarios in which your system or application interacts with
people, organizations, or external systems
 Goals that your system or application helps those entities
(known as actors) achieve
 The scope of your system
When to apply use case diagrams

A use case diagram doesn't go into a lot of detail—for example, don't expect it to model the order in
which steps are performed. Instead, a proper use case diagram depicts a high-level overview of the
relationship between use cases, actors, and systems. Experts recommend that use case diagrams be
used to supplement a more descriptive textual use case.

UML is the modeling toolkit that you can use to build your diagrams. Use cases are represented with a
labeled oval shape. Stick figures represent actors in the process, and the actor's participation in the
system is modeled with a line between the actor and use case. To depict the system boundary, draw a
box around the use case itself.

UML use case diagrams are ideal for:

 Representing the goals of system-user interactions

 Defining and organizing functional requirements in a system

 Specifying the context and requirements of a system

 Modeling the basic flow of events in a use case

Use case diagram components

To answer the question, "What is a use case diagram?" you need to first understand its building
blocks. Common components include:

 Actors: The users that interact with a system. An actor can be a person, an organization, or an
outside system that interacts with your application or system. They must be external objects
that produce or consume data.

 System: A specific sequence of actions and interactions between actors and the system. A
system may also be referred to as a scenario.

 Goals: The end result of most use cases. A successful diagram should describe the activities
and variants used to reach the goal.

This use case diagram is a visual representation of the process required to write and publish a book.
Whether you’re an author, an agent, or a bookseller, inserting this diagram into your use case
scenario can help your team publish the next big hit
Determining requirements for information systems projects

What is requirements analysis (requirements engineering)?

Requirements analysis (requirements engineering) is the process of determining user expectations for a
new or modified product. It is usually a team effort and demands a variety of human soft skills, such as
critical thinking, communication and judgment.

Requirements analysis is a common and essential concept in software development and

software project management. At the start of every software project, the project team must
understand, finalize and document the features and functionalities required of the end product. These
required features and functionalities are often called functional specifications, and the process of
determining and understanding them is called requirements gathering and analysis.

Requirements must be quantifiable, as detailed as possible and relevant to the end product. In addition,
they should be clearly documented so the development team has clear expectations and understands
required specifications from the beginning.

Requirements analysis in software engineering does the following:

 Clarifies the required features and overall vision of a new product.

 Clarifies stakeholder expectations for that product.

 Prevents conflict and communication gaps during development and testing.

 Ensures that the final product conforms to requirements, i.e., prevents scope creep.

The importance of communication during requirements analysis

During requirements analysis, project team members come together to understand the project goals,
clarify expectations and document the product's required specifications and features. All of this requires
clear and unambiguous communication between team members.

When gathering requirements, the project team should also communicate with other stakeholders, such
as the project owner and end users, to determine their expectations regarding specific features. Early
and frequent discussions between these parties help to prevent ambiguity. It ensures that the final
product conforms to the end user's or client's needs and avoids forcing users to adjust their
expectations.

Requirements analysis process

Requirements analysis is a multistage process that involves the following steps.

1. Understand the key stakeholders and end users

In any project, the key stakeholders, including end users, generally have final say on the project scope.
Project teams should identify them early and involve them in the requirements gathering process from
the beginning.

2. Understand the project goal

To capture all necessary requirements, project teams must first understand the project's objective.
What business need drives the project? What problem is the product meant to solve? By understanding
the desired end, the project team can define the problem statement and have more productive
discussions when gathering requirements.

3. Capture requirements

At this stage, all relevant stakeholders provide requirements. This can be done through one-on-one
interviews, focus groups or consideration of use cases. Project teams gather stakeholder feedback and
incorporate it into requirements.

4. Categorize requirements

Categorization of requirements can help with prioritization, impact analysis, feasibility analysis and
conflict resolution. Four common requirements categories are the following:

1. Functional requirements.

2. Technical requirements.

3. Transitional requirements.

4. Operational requirements.

5. Interpret and document requirements

Post-categorization, the project team should analyze its set of requirements to determine which ones
are feasible. Interpretation and analysis are easier when requirements are well defined and clearly
worded. Each requirement should have a clear and understood impact on the end product and the
project plan. After all the requirements have been identified, prioritized and analyzed, project teams
should document them in the software requirements specification (SRS).

6. Finalize SRS and get sign-off on requirements

The SRS should be shared with key stakeholders for sign-off to ensure that they agree with the
requirements. This helps prevent conflicts or disagreements later. Feedback, if any, should be
incorporated. The SRS can then be finalized and made available to the entire development team. This
document provides the foundation for the project's scope and guides other steps during the software
development lifecycle (SDLC), including development and testing.

It’s very important that you understand the system’s purpose and determine its requirements.
Designing a system based on its requirements is much easier than going back and trying to fix things
later.

Requirements modeling

There are a lot of different definitions for the word model. But generally a model is a representation of a
thing or a system that you want to build. Models can help you to identify any potential problems that
you might run into before investing too much time or money in building at full scale. So basically, a
requirements model is a structured, visual representation of what needs to be included in your
information systems projects.

Requirements modeling is critical to the success of your projects because:

 It helps you develop processes to quickly deliver consistent products.

 It helps the development team to have a better understanding of the product and processes.

 You can give stakeholders and clients a detailed plan that addresses their specific requirements.

 It invites collaboration and rapid feedback that can decrease the risk of problems later on in the
project.

It helps new team members to get a handle on the project so they have a better understanding of what
their role is in the project.

It makes it easier to create simulations.

It lets you manage changing requirements requests.

Project planning and information gathering

So where do you start? How do you figure out what the requirements are, and how do you determine
the purpose of your information system? Following are some steps that can help you to plan and gather
information for your project. Following these steps can help you to find and fix problems faster,
streamline development, and ultimately develop high-quality products on a consistent basis.

Determine the system’s purpose

Why are you designing the information system? What type of information will be stored? Understanding
the purpose will help you make better decisions for your design. For example, you might be modeling a
system for storing information such as customer ID and transactions, team members and skill sets, or
service-level agreement contracts and renewal dates.

Starting with a written statement about what you want the system to accomplish makes the design and
modeling process much easier.

Gather information

You might want to start your information gathering by looking at existing data. You can analyze it to see
what works well and what may need to be fixed. And you can determine what existing information can
be used in your new system. Following are additional methods you can use to gather important
information.

Mind mapping

While brainstorming is more about generating a lot of ideas quickly, mind mapping is more about
identifying a central concept and surrounding it with related ideas and information.

For example, the system’s stated purpose might be the mind map’s central idea. From there you draw
branches and nodes that represent different system modules radiating out from the center. The
branches show the relationship to the central idea as well as the relationships and concepts among the
modules. Then you draw sub-branches that describe module functionality.

Mind mapping is a free-flowing, creative approach to note-taking and outlining. It lets you document
your thoughts with images and words and helps you to more clearly see and understand the
relationships and connections among various concepts.

A mind map is a visual representation of your thoughts that more closely resembles how your brain
works. The images and colors used to create your mind maps help you to understand and retain
information for a longer period of time.

Identify entities, attributes, and relationships

Creating data model mockups can help you to organize data and define the relationships among data
elements. Data modeling is a technique used to create a visual representation of your company’s
business data, how it’s organized, and how it flows by analyzing and determining the data
requirements.

Data mockup modeling is important because it gives you the following benefits:

 Cuts costs and reduces time to market

 Improves business processes and streamlines development, ensuring consistent and high-quality
product releases

 Reduces complexities and risks

  Improves collaboration among various teams and stakeholders

Create an ER diagram

An ER diagram is similar to a data flow chart. You use ER diagrams to document and illustrate the logical
structure of your database, and to show how pieces of data (entities) relate to each other in your
system.

Think of an entity as a noun. It is something that has data stored about it. For example, a customer or a
pizza. Entities have attributes that define characteristics belonging to each entity. For example, the
name of the customer entity and the type of pizza entity (cheese, pepperoni, combo, etc.).

Entities can be put into entity sets—a collection of entities that share the same attributes but might
have different values for some of the attributes. For example, you might put a lot of Student entities in
one set, but the value for each Name attribute will be different.

After you have defined the entities and attributes, it’s time to identify and define the relationships. A
relationship describes the connection or association between one or more instances of entity types.
Relationships can be thought of as verbs or verb phrases. For example, the customer’s name is Bob.
Customer Bob bought a pepperoni pizza.

But you aren’t simply showing a relationship between two entities. You need to define what type of
relationship it is. We’ll use entity sets A and B as an example:

 One-to-one: One record in A corresponds to one record in B. For example, a student might be
registered in a Physics of Sound and Acoustics course. The student might be enrolled in several
different courses but only one Physics of Sound and Acoustics course.

 One-to-many: One record in A corresponds to many records in B. For example, a single car
company produces many different car models. But a specific model is built only by a specific car
company.

 Many-to-one: Many records in A correspond to at most one record in B. For example, many
different students have enrolled in one Physics of Sound and Acoustics class.

 Many-to-many: Many entities in A correspond to many entities in B. For example, many

different car companies build many different car models.

ER diagrams use shapes like rectangles, ovals, and diamonds—similar to the shapes you might see in a
flowchart—to represent different types of entities, their attributes, and relationships. Specific lines are
used to describe entity connections and cardinality (for example relationships that can be described as
one-to-one, one-to-many, many-to-many, and so on).

The benefits of creating ER diagrams include:

 They are easy to understand and are useful for communicating requirements and architecture
with developers, customers, stakeholders, and end users no matter how technical or non-
technical they might be.

 They help you to understand relationships between entities which can help you to find
ambiguities or unnecessary processes.

 ER diagrams translate into relational tables which can help you to build databases more quickly.

 Database developers can use the diagrams as blueprints for implementing data in software
applications.

 They can be useful in other contexts such as describing relationships within an organization.

Drafting a requirements document

Everything you have done to this point will help you to determine what the requirements are for your
project. The requirements document establishes the project’s purpose and summarizes the
requirements. It also includes any mockups and models that have been built.

When you write a requirements document, use language that is easy for everybody to understand.
Don’t use jargon that might confuse your intended audience. Not everybody who will use this document
will be skilled technically.

Be sure to review the document with stakeholders and subject matter experts to ensure that it is correct
and includes everything that is needed.

d) OBJECT ORIENTED ANALYSIS AND DESIGN

Object-Oriented Analysis and Design (OOAD) is a software engineering methodology that involves using
object-oriented concepts to design and implement software systems. OOAD involves a number of
techniques and practices, including object-oriented programming, design patterns, UML diagrams, and
use cases. Here are some important aspects of OOAD:

1. Object-Oriented Programming: Object-oriented programming involves modeling real-world

objects as software objects, with properties and methods that represent the behavior of those
objects. OOAD uses this approach to design and implement software systems.
 2. Design Patterns: Design patterns are reusable solutions to common problems in software design.
OOAD uses design patterns to help developers create more maintainable and efficient software
systems.

3. UML Diagrams: Unified Modeling Language (UML) is a standardized notation for creating
diagrams that represent different aspects of a software system. OOAD uses UML diagrams to
represent the different components and interactions of a software system.

1. Use Cases: Use cases are a way of describing the different ways in which users interact with a
software system. OOAD uses use cases to help developers understand the requirements of a
system and to design software systems that meet those requirements.

There are several advantages to using OOAD in software engineering:

1. Reusability: OOAD emphasizes the use of reusable components and design patterns, which can
save time and effort in software development.

2. Scalability: OOAD can help developers design software systems that are scalable and can handle
changes in user demand and business requirements over time.

3. Maintainability: OOAD emphasizes modular design and can help developers create software
systems that are easier to maintain and update over time.

4 Flexibility: OOAD can help developers design software systems that are flexible and can adapt to
changing business requirements over time.

However, there are also some potential disadvantages to using OOAD:

1. Complexity: OOAD can be complex and may require significant expertise to implement effectively.

2.Time-consuming: OOAD can be a time-consuming process that involves significant upfront

planning and documentation.

3.Rigidity: Once a software system has been designed using OOAD, it can be difficult to make
changes without significant time and expense.

4.Cost: OOAD can be more expensive than other software engineering methodologies due to the
upfront planning and documentation required.

Overall, OOAD can be an effective approach to designing and implementing software systems,
particularly for complex or large-scale projects. However, it’s important to weigh the advantages and
disadvantages carefully before adopting this approach
 Object-Oriented Analysis (OOA) is the first technical activity performed as part of
object-oriented software engineering. OOA introduces new concepts to investigate a
problem. It is based on a set of basic principles, which are as follows-
1. The information domain is modeled.
2. Behavior is represented.
3. The function is described.
4. Data, functional, and behavioral models are divided to uncover greater detail.
5. Early models represent the essence of the problem, while later ones provide implementation
details.

Object-Oriented Design (OOD): An analysis model created using object-oriented

analysis is transformed by object-oriented design into a design model that works as a
plan for software creation. OOD results in a design having several different levels of
modularity i.e., The major system components are partitioned into subsystems (a
system-level “modular”), and data manipulation operations are encapsulated into
objects (a modular form that is the building block of an OO system.). In addition, OOD
must specify some data organization of attributes and a procedural description of each
operation. Shows a design pyramid for object-oriented systems. It is having the
following four layers.

1. The Subsystem Layer : It represents the subsystem that enables software to achieve user
requirements and implement technical frameworks that meet user needs.

2. The Class and Object Layer : It represents the class hierarchies that enable the system to
develop using generalization and specialization. This layer also represents each object.

3. The Message Layer : It represents the design details that enable each object to communicate
with its partners. It establishes internal and external interfaces for the system.

4. The Responsibilities Layer : It represents the data structure and algorithmic design for all the
attributes and operations for each object.

The Object-Oriented design pyramid specifically emphasizes specific product or system design. Note,
however, that another design layer exists, which forms the base on which the pyramid rests. It focuses
on the core layer the design of the domain object, which plays an important role in building the
infrastructure for the Object-Oriented system by providing support for human/computer interface
activities, task management.

Advantages of OOAD:

1. Improved modularity: OOAD encourages the creation of small, reusable objects that can be
combined to create more complex systems, improving the modularity and maintainability of the
software.
 2. Better abstraction: OOAD provides a high-level, abstract representation of a software system,
making it easier to understand and maintain.

3. Improved reuse: OOAD encourages the reuse of objects and object-oriented design patterns,
reducing the amount of code that needs to be written and improving the quality and consistency
of the software.

4. Improved communication: OOAD provides a common vocabulary and methodology for software
developers, improving communication and collaboration within teams.

5. Reusability: OOAD emphasizes the use of reusable components and design patterns, which can
save time and effort in software development by reducing the need to create new code from
scratch.

6. Scalability: OOAD can help developers design software systems that are scalable and can handle
changes in user demand and business requirements over time.

7. Maintainability: OOAD emphasizes modular design and can help developers create software
systems that are easier to maintain and update over time.

Disadvantages of OOAD:

1. Complexity: OOAD can add complexity to a software system, as objects and

their relationships must be carefully modeled and managed.
2. Overhead: OOAD can result in additional overhead, as objects must be
instantiated, managed, and interacted with, which can slow down the
performance of the software.
3. Steep learning curve: OOAD can have a steep learning curve for new
software developers, as it requires a strong understanding of OOP concepts
and techniques.
4. Complexity: OOAD can be complex and may require significant expertise to
implement effectively. It may be difficult for novice developers to understand
and apply OOAD principles.
5. Time-consuming: OOAD can be a time-consuming process that involves
significant upfront planning and documentation. This can lead to longer
development times and higher costs.
6. Rigidity: Once a software system has been designed using OOAD, it can be
difficult to make changes without significant time and expense. This can be a
disadvantage in rapidly changing environments where new technologies or
business requirements