-ARC-REC-002

ASSIGNMENT COVER

REGION:
____HARARE_______________________________________________________________
__

PROGRAMME: _BACHELOR OF SCIENCE IN INFORMATION

TECHNOLOGY____________________________(BSITZ)______________________
INTAKE: _2.2___

FULL NAME OF STUDENT: GRACIOUS MARTHA

GONESE______________________________________ PIN: __P2292741F______

MAILING ADDRESS:
____gonesegracious8@gmail.com_______________________________________________
_______

CONTACT TELEPHONE/CELL: __0772931051_______________________ ID. NO.: _59-

190495T83_______________

COURSE NAME: ____REQUIREMENTS

ENGINEERING__________________________________ COURSE CODE:
BSSE241_________

ASSIGNMENT NO _______1____________________ DUE DATE: __10

Semptember____2024_______

ASSIGNMENT TITLE: ___REQUIREMENTS ENGINEERING ASSIGNMENT

1_____________________________________________________

___________________________________________________________________________
___
___________________________________________________________________________
___

MARKER’S COMMENTS:
______________________________________________________
___________________________________________________________________________
___
___________________________________________________________________________
___

___________________________________________________________________________
___
OVERALL MARK: _____________ MARKER’S NAME: ________________________

MARKER’S SIGNATURE: _______________________________ DATE: ___________

Issue Date: 3 October 2013

BSEH/BSSE 241: REQUIREMENT ENGINEERING

1.A small specialist language training company would like to improve the services offered to
existing clients and increase its client base by replacing existing call centre and paper-based
mailshots, with online web technology deployment.

Discuss whether it is advantageous for the company to continue requirements engineering

beyond the first phase of the development process. [10]

Answer

Advantages of Continuing Requirements Engineering

It is highly advantageous for the company to continue requirements engineering beyond the
first phase of the development process. This approach enhances understanding and adaptability
but also mitigates risks, improves communication, and increases the quality of the final
product. As the training company aims to replace outdated methods with modern technology,
a robust requirements engineering process will be essential for successful implementation and
client satisfaction.

Continuing requirements engineering beyond the first phase of the development process can
provide several significant advantages for a company looking to improve its services and
expand its client base through online technology deployment.

1. Enhanced Understanding of Client Needs:

Continuing requirements engineering allows for a deeper understanding of client needs and
expectations. As the company transitions from traditional methods like call centers and paper-
based mailshots to online solutions, ongoing engagement with clients can reveal insights that
may not have been apparent initially. This iterative process helps in refining the requirements
based on real user feedback, ensuring that the final product aligns closely with client
expectations.

2. Adaptability to Changing Requirements:

The business environment is dynamic, and client needs can evolve over time. By maintaining
a continuous requirements engineering process, the company can adapt to these changes more
effectively. This flexibility is crucial in technology deployment, where new features or
adjustments may be necessary as the online platform is developed and used.

3. Risk Mitigation:

Continuing requirements engineering helps in identifying potential risks early in the

development process. By regularly revisiting and validating requirements, the company can
address issues before they escalate, reducing the likelihood of costly changes later in the
project. This proactive approach can lead to a smoother implementation of the new online
systems.

4. Improved Stakeholder Communication:

Ongoing requirements engineering fosters better communication among stakeholders,

including clients, developers, and management. Regular updates and discussions about
requirements can ensure that everyone is aligned and that any concerns are addressed promptly.
This collaborative environment can enhance trust and satisfaction among clients.

5. Increased Quality of Deliverables:

By continuously refining requirements, the quality of the final deliverables is likely to improve.
A well-defined set of requirements leads to better design and implementation, ultimately
resulting in a more effective online service that meets client needs and expectations.

2.Describe the requirements engineering processes. [10]

Requirements Engineering is a systematic and strict approach to the definition, creation and
verification of requirements for a software system. To guarantee the effective creation of a
software product, the requirements engineering process entails several tasks that help in
understanding, recording, and managing the demands of stakeholders.
Requirements Engineering Process:
1.Feasibility Study involves
Technical Feasibility, Operational Feasibility and Economic Feasibility
2.Requirements elicitation
Requirements elicitation is the process of gathering information about the needs and
expectations of stakeholders for a software system.
Techniques can be used to elicit requirements, including:
Interviews are one-on-one conversations with stakeholders to gather information about their
needs and expectations.
Surveys done using questionnaires that are distributed to stakeholders to gather information
about their needs and expectations.
Focus Groups are small groups of stakeholders who are brought together to discuss their needs
and expectations for the software system.
Observation is a technique that involves observing the stakeholders in their work environment
to gather information about their needs and expectations.
Prototyping is another technique that involves creating a working model of the software
system, which can be used to gather feedback from stakeholders and to validate requirements
3.Requirements specification
Requirements specification is the process of documenting the requirements identified in the
analysis step in a clear, consistent, and unambiguous manner. This step also involves
prioritizing and grouping the requirements into manageable chunks.
Several types of requirements are commonly specified in this step, including Functional
Requirements, these describe what the software system should do. They specify the
functionality that the system must provide, such as input validation, data storage, and user
interface.
Non-Functional Requirements: These describe how well the software system should do it.
They specify the quality attributes of the system, such as performance, reliability, usability,
and security.
Constraints, these describe any limitations or restrictions that must be considered when
developing the software system.
Acceptance Criteria, these describe the conditions that must be met for the software system to
be considered complete and ready for release
Requirements for verification and validation.
To make the requirements specification clear, the requirements should be written in a natural
language and use simple terms, avoiding technical jargon, and using a consistent format
throughout the document. It is also important to use diagrams, models, and other visual aids to
help communicate the requirements effectively.
Once the requirements are specified, they must be reviewed and validated by the stakeholders
and development team to ensure that they are complete, consistent, and accurate.
4. Requirements Verification and Validation
Verification refers to the set of tasks that ensures that the software correctly implements a
specific function.
Validation refers to a different set of tasks that ensures that the software that has been built is
traceable to customer requirements. If requirements are not validated, errors in the requirement
definitions would propagate to the successive stages resulting in a lot of modification and
rework. The main steps for this process include:
The requirements should be consistent with all the other requirements for example no two
requirements should conflict with each other. The requirements should be complete in every
sense. The requirements should be practically achievable. Reviews, buddy checks, making test
cases, etc. are some of the methods used for this.
5. Requirements Management
Requirement management is the process of analyzing, documenting, tracking, prioritizing, and
agreeing on the requirement and controlling the communication with relevant stakeholders.
Several key activities are involved in requirements management, including: Tracking and
controlling Changes-This involves monitoring and controlling changes to the requirements
throughout the development process, including identifying the source of the change, assessing
the impact of the change, and approving or rejecting the change.
Version Control-This involves keeping track of different versions of the requirements
document and other related artifacts.
Traceability - This involves linking the requirements to other elements of the development
process, such as design, testing, and validation.
Communication is key that the requirements are communicated effectively to all stakeholders
and that any changes or issues are addressed promptly. Monitoring and reporting involve
monitoring the progress of the development process and reporting on the status of the
requirements.
Requirements management is a critical step in the software development life cycle as it helps
to ensure that the software system being developed meets the needs and expectations of
stakeholders and that it is developed on time, within budget, and to the required quality. It also
helps to prevent scope creep and to ensure that the requirements are aligned with the project
goals.

3.Discuss the important issues that a SRS must address. [10]

A Software Requirements Specification (SRS) is a document that lays out the description of
the software that is to be developed as well as the intention of the software under development.
Software requirements specification shows what the software is supposed to do as well as how
it is supposed to perform. It is written down before the actual software development work starts.
An SRS should address, among other things:

Functionality of the software: What the software will do

External interfaces: How the given software will interact with hardware, other software(s), and
assumptions on these entities
Required performance levels: Required performance levels such as response rate, recovery rate,
etc. of the software
Quality attributes: The non-functional factors that are used to evaluate the performance of the
software, such as security, safety, portability, etc
Design constraints: Any operating system limitations (e.g.: the stock exchange software will
only run on Windows), implementation language, etc that will affect or limit the design of the
software.
Non-functional Requirements
Performance Requirements
Requirements such as RAM requirements, CPU speed, etc. These will ensure the software
performs smoothly and without any problems
Business Rules
The operating principles of the product are stated here. Such as which individuals can perform
which functions under different circumstances.
Addressing system goals and requirements that they are different: Goal is a more general
characteristics.” e. g. Whole system should be designed in a user friendly manner or more
robust system”. Requests are more testable in nature. For example all users command selection
should be only using pop up menus .
Request Definition: A statement in a natural language stating what services the system should
expected to provide. It should be understandable by clients, contractors, management & users.
Request Specification: A structured document maintaining the services in more details than
definition, and precise enough to act as a contract. It should be understandable by technical
staff both at a developer and producer’s place.
Software Specification (Design Specification): It is an abstract design description of the
software which is the basis for design and implementation. There should be a clear relationship
between this documents and the software request specification. The reader of this document is
software engineer, system analyst and project leaders.
Requirement Capture and Analysis: It is the process of designing the system request captures
through: - (i) Observation of existing system. (ii) Discussion with potential users, producers.
(iii) Personal interviews and task analysis. (iv) Standard published documents/reports from the
user.
Feasibility Study: (i) It is estimate made weather the identified user needs can be satisfied
using the current technology. (ii) Weather the proposed system is cost effective. (iii) Weather
it is possible to develop the system within the budgetary and time constraints.
Suggestions for preparing an SRS Document: (i) Only specify external system behavior.
(ii)Specifying the constraints on implementation. (iii)It should record for thought about the life
cycle of the system. (iv) It should characterize acceptable responses to the undesired events.
Safety Requirements
Requirements concerned with possible loss, damage or harm that could result from the use of
the product are stated here. Any safeguards that must be implemented should also be defined.
External policies or regulations stating safety issues that affect the product’s design or use
should be referred. Any safety certifications that must be satisfied is defined.

Security requirements
This part specifies any requirements regarding privacy and safety, as well as the protection of
data created or used by the product. Any user identity authentication requirements are stated
here. Any safety certifications that need to be satisfied is also defined.

Software Quality Attributes

Any additional quality characteristics of the product that might be important are specified here.
Such as adaptability, interoperability, availability, correctness, maintainability, robustness,
usability, testability, etc. These are written in a specific, verifiable, and quantitative way.

Other requirements
Any requirements not stated in the SRS elsewhere are stated here. The requirements may
include database requirements, legal requirements, etc.

4.A company is looking to develop a new proprietary software application that can
compete amongst current social media platforms. As Chief Analyst, give an outline of the
different stages of requirements engineering, and discuss the tools and techniques that
you would adopt to derive a complete and consistent requirements specification from the
company. [20]

As Chief Analyst, I would outline the following stages of requirements engineering to develop
a complete and consistent requirements specification for the new proprietary software
application such as elicitation, analysis, specification, management. The tools and techniques
that I would adopt to derive a complete and consistent requirements specification from the
company are Interviews and Surveys, use case modelling, prototyping and requirement
management tools.
Requirements engineering is a systematic process that involves gathering, analyzing,
documenting, and managing the requirements for a software system.

The stages of requirements engineering typically include:

Elicitation: This stage involves gathering requirements from stakeholders, such as users,
customers, and domain experts. Techniques like interviews, surveys, and workshops can be
used to elicit requirements.
- Identify stakeholders: Company executives, end-users, marketing team, and technical team
- Conduct interviews, surveys, and focus groups to gather requirements
- Analyze competitors and market trends

Analysis: In this stage, the gathered requirements are analyzed to identify inconsistencies,
conflicts, and missing information. Techniques like requirement prioritization, use case
modeling, and scenario analysis can be used to analyze the requirements.
- Categorize and prioritize requirements using techniques like MoSCoW method

- Identify functional and non-functional requirements

- Develop a high-level system architecture

Specification: The requirements are documented in a clear and unambiguous manner. This
stage involves creating requirement documents, such as a requirements specification document
or a use case document. The requirements should be organized, structured, and traceable.
- Create a detailed and formal requirements specification document

- Use natural language, diagrams, and models to describe requirements

- Include use cases, user stories, and acceptance criteria

Validation: The requirements are validated to ensure that they are complete, consistent, and
feasible. Techniques like reviews, inspections, and prototyping can be used to validate the
requirements. Validation helps in identifying and resolving any issues or ambiguities in the
requirements.

- Review and verify requirements with stakeholders

- Check for completeness, consistency, and feasibility

- Conduct requirements walkthroughs and inspections

Management: Requirements are managed throughout the software development lifecycle.

This involves tracking changes to the requirements, maintaining traceability, and ensuring that
the requirements are up to date. Tools like requirement management systems can be used to
manage the requirements.
Tools and Techniques for Deriving Complete and Consistent Requirements
To derive a complete and consistent requirements specification for the company's proprietary
software application, the following tools and techniques can be adopted:
- Establish a requirements management plan

- Use tools like requirements management software (e.g., JIRA, DOORS)

- Track changes, updates, and approvals

Tools and techniques

Interviews and Surveys: Conducting interviews and surveys with stakeholders can help gather
their requirements and expectations for the software application. This can provide valuable
insights into the desired features, functionalities, and user experience.
Use Case Modeling: Use case modeling is a technique for capturing functional requirements.
It helps in identifying the actors, their goals, and the interactions between the actors and the
system. Use case diagrams and use case scenarios can be used to document the requirements.
Prototyping: Building prototypes of the software application can help validate and refine the
requirements. Prototypes allow stakeholders to visualize and interact with the proposed system,
providing feedback and identifying any gaps or changes needed in the requirements.
Requirements Workshops: Conducting requirements workshops with stakeholders can
facilitate collaboration and consensus building. Workshops can be used to clarify requirements,
resolve conflicts, and prioritize features. Techniques like brainstorming and group discussions
can be employed in these workshops.
Requirement Management Tools: Using requirement management tools can help in
organizing, documenting, and tracking the requirements. These tools provide features like
version control, traceability, and collaboration, which are essential for managing the
requirements throughout the software development lifecycle.
By adopting these tools and techniques, the Chief Analyst can ensure a comprehensive and
consistent requirements specification for the company's proprietary software application. This
will help in developing a competitive product that meets the needs and expectations of the
stakeholders. Proprietary software application:
- Requirements gathering: Interviews, surveys, focus groups, competitor analysis

- Requirements analysis: MoSCoW method, use cases, user stories

- Requirements specification: Natural language, diagrams (e.g., UML, BPMN), models (e.g.,
data flow diagrams)

- Requirements validation: Walkthroughs, inspections, review meetings

- Requirements management: Requirements management software, version control systems

To sum up as chief analyst, I will develop a new proprietary software application that can
compete amongst current social media I would use strategies like elicitation whereby we
gather requirements from stakeholders, such as users, customers, and domain user stage as well
as validating to ensure that they are complete, consistent, and feasible. I can use prototyping as
a way of reusing my tools and techniques.