MIS604 Requirements Engineering
Agile Requirements Analysis & Management Report
Students Name
Students Number
Lecturer’s Name
1
Contents
Introduction.......................................................................................................................... 2
Minimum Viable Product.....................................................................................................3
Story Mapping.................................................................................................................... 4
Product Backlog and Roadmap..........................................................................................5
Acceptance Criteria for User Story.....................................................................................6
Similarities and Differences between Traditional & Agile Analysis......................................7
Conclusion............................................................................................................................ 7
References............................................................................................................................ 8
2
Introduction
Requirement engineering is a complete process which helps in conforming of engineering
designs to those of the requirements set by the system. This is the most important feature in
software engineering to create results accurately. In this subject, an engineer looks at the
data set which contains the objectives and goals of the software; qualities, properties and
how will the software work and the results that are expected from the software. Then the
engineer proceeds to look at the specific coding required to achieve these results through
the software. Analyzing these requirements are an integral and key part of any system,
software or for project development and management. With the help of this analysis an
engineer can track, train and understand the software as well as control it too(Inkermann et
al., 2019, p. 240). Whether dealing with business, academic, or professional, before
achievement and visualization of the real goal, requirements exploration is necessary in all
aspects of life.
During my academic tenure too, I utilized my course knowledge of requirements engineering
to formulate a working plan according to the set of expectations, analyze my course
expectations, and link my efforts in line to output maximum performance.
Within this report, I will be clearly illustrating the concepts of requirement engineering and its
significant contributions to my general life performance, academic life, achievements, and
performance in general life. The acquired knowledge in this domain helps insetting a good
precedent for me across these avenues.
Minimum Viable Product
My study of requirements engineering has nurtured a strong scope analysis in any project
undertaken, and problem-solving ability especially in my academic and general life. This
course has also helped me in thoroughly assessing all the risks involved in my career path
and professional life, all the possible failures as well as solutions to those failures if and
when they occur to help achieve a breakthrough. This helps me by creating a high
perseverance in me as a scholar to develop, manage and plan a reliable system of
actualization of project, and analyze possible failures and risks while following a pathway to
system fulfilment. Some of the concepts related to risk management, planning, trading off,
acceptance, and change control learned in the subject of requirements engineering, has
successfully increased my chances of running a project or a developing a system that is
successful(Inkermann et al., 2019, p. 240). This course has also paved path to the dynamics
of success through qualitative collection of necessary information, statement of
3
requirements, management support for any system, and proper planning for a system to
attain high chances of success.
Minimum Viable Product (MVP) is a necessary component in requirements engineering and
it simply means creation of the original product but no more than a landing page or a service
that seems automated but is manual and offer the customers with the actual behavior as the
product or service promises. This helps in seeing what the customer does which is much
better then asking customers what things need to be implemented.
Story Mapping
Following the academic assessment for the case study, the goal of the company was to
implement a website, for the development and analysis of a minimum viable product (MVP),
to provide better experience to the users of the website, in turn obtaining customer feedback
on the company delivery in order to help improve their business reviews. With the help of the
knowledge, I have attained through the in-depth study of requirement engineering, I have
incorporatedthat meeting stakeholders (customers, developers, users, and business) is
equally important and their needs need priority which can be done by analyzing their wants
from the company. By prioritizing the needs of the customers, the company has already
made it easy to meet customer goals and improve the functionality as customers’ demands
are ever changing and need to be incorporated to meet the goals. I have thoroughly
assessed the evolving needs of the customer and ensured that the project can withstand
technology and time changes, that will help with scalability in the future. I also did a thorough
analysis about the website development needs and customer feedback, and the outcome
preferences that are in line with the customers’ communication preferences. I further
addressed the user-friendliness of the website, and how company can make the least
possible efforts to meet customer preferences. This was done with the help of random
questionnaires with potential customers, taking & incorporating necessary feedback about
their preferences for website design. This applied my knowledge of requirements
engineering in order to assess complexities during project development as well as interlink
the individual components to achieve the maximum product capability while meeting the
needs of the (Inkermann et al., 2019, p. 242).
Product Backlog and Roadmap
The two of the most significant items are product backlog and product roadmap. Each of
these instruments have their own qualities and shortcomings:
The item guide is an obvious level device that helps a thing overseer to figure out, get, and
give their thing's fundamental plans just as destinations. Investigating your aide you are
4
should fail to remember where you are taking the thing from for the following not many
months (and even a long time), similarly as your fundamental suspecting for doing
accordingly—whether or not this is an immediate aftereffect of a possibility you've
recognized keeping watch, relentless squeezing factor, strong customer premium, or a blend
of components. Customary things on an aide will join unquestionable level thing stories and
maybe subjects. In the interim the item build-up records and spotlights on the task level
nuances that are expected to execute every one of the fundamental courses of action that
are set out in the aide. (Pichler, 2020). An expedient gander at your development is
important to check what is next in your improvement gathering's everyday plan while they
are occupied in executing on your aide's elevated perspective vision. Normal things on a
thing develop fuse bug fixes, thing stories, and various tasks.
Each client story should be evaluated so much that it will in general be done in a solitary run.
If the venture is greater than what should be possible in a singular run, then, at that point it is
your obligation as a thing chief to separate it. The most notable story pointing structures
uses the Fibonacci course of action to evaluate relative bigness.
There will be circumstances where you will manage a story that you should traverse various
runs, a bigger task, or another component. You will have a bunch of client stories to achieve
your errand yet need an approach to remain coordinated and get when the venture or
highlight is "finished". In these circumstances we utilize a develop called an epic. Legends
are just bigger client stories. They are utilized to bunch client stories that when conveyed
bring about the finishing of a venture or enormous component. Actually, like client stories,
sagas likewise have a start and an end. When the task is finished, or highlight conveyed the
epic is shut.
Agile Scrum is astonishing in how its straightforwardness controls the right requests to the
surface. If the Epic is too uncertain or astounding or both it is inept to check its work. The
Product Owner declines complexity by making Product Backlog Items (stories). Overall, the
more stories supporting an Epic, the less the overall weakness and complexity. As these
records are also broken down into more stories, each story advances toward an effort check
as per as far as possible benchmark.
Acceptance Criteria for User Story
Now we will discuss the acceptance criteria for our user story. Acceptance criteria simply
mean that the story that was to be defined is completed and all the functionality demanded
by users has been successfully implemented in the system. These are simply some sets of
conditions that need to be fulfilled to mark the project as complete and enables team to
5
process data efficiently. This can include details such as the experience of users, effect on
existing features, key performance metrics and what the story intended to achieve.
Due to the project's design path,it was necessary to characterize the website requirements
in terms of requirements of system, needs of stakeholders, and needs of components or
applications. With the help of the above criterion, I was able to break down the complete
project to the planned platform, build, domain name required for the website, color schemes,
web hosts, rating system and the available payment methods for customers. With the help of
the customer feedback from questionnaires, these design requirements became very easy to
be met. By analyzing the market trends, entry barriers, and MVP development risks, it also
became easy to analyze the market impact and the costs that could be incurred as the result
of the [Link] was then easily validated through concepts acquired from requirements
engineering. To conclusively build a well-analyzed report on the MVP, the idea of
transformation process, and requirement management was applied by me. This involved a
thorough analysis, documentation, research, observation, and verification of the
requirements expectations in order to carry out disruptions and modifications necessary to
build a clear report (La Paz & Vásquez, 2019, p. 80).
Similarities and Differences between Traditional & Agile Analysis
Requirement evaluation concepts made it easier to make informed decisions in order to
meet the goals needed based on the capabilities, background, knowledge, future plans, and
life (Ghozali et al., 2019, p. 275). This also helped us tremendously in regular
communication with stakeholders to understand their needs and meet their expectations
without interfering with their plan.
There have been many similarities between agile requirements analysis & management as
well as traditional requirements analysis & management. The first goal similar between the
two is that the requirements have the same goal at the very end, developing a good quality
solution or product and meeting the requirements of the stakeholders. The second goal is to
write well written user stories that are concise, complete, and clear. Both methods share the
same similarity that even if all requirements cannot suggest a solution, they must not
constrain the solution in any way. (Kashyap, 2021)
The key difference between the agile system and traditional requirement analysis is the
project phases sequence – gathering, planning, development, design, UAT, and testing the
requirements. Agile method follows an iterative process while traditional method follows a
linear process for project completion. Agile requirements are written in the form of user
stories which differs from the traditional requirement analysis approach. While traditional
6
requirement analysis cannot incorporate changes during the development of project, agile
requirement analysis is flexible and can incorporate such changes during the development of
the project.
Conclusion
Covering this assessment has helped me to gain a detailed understanding of the
requirements as well as the need for project analysis. This equips me with management
skills required, and the scope assessments in my career path and academic life is
satisfactory. Through transformation processes such as destruction and recreation of project
requirements has given me an opportunity to replan life goals as well as work on course
projects avoiding the possible errors. Requirement engineering is part and parcel for the
successof any project. As a unit, it has given extensive exposure to problem assessment,
project requirements, and problem management.
7
References
Ozali, R. P., Saputra, H., Nuriawan, M. A., Suharjito, N. M. A., Utama, D. N., & Nugroho, A.
(2019). Systematic Literature Review on Decision-Making of Requirement
Engineering from Agile Software Development. Procedia Computer Science, 157,
274-281. doi:10.1016/[Link].2019.08.167. Retrieved from [Link]
[Link]/science/article/pii/S1877050919310853
Inkermann, D., Huth, T., Vietor, T., Grewe, A., Knieke, C., & Rausch, A. (2019). Model-
Based Requirement Engineering to Support Development of Complex Systems.
Procedia CIRP, 84, 239-244. doi:10.1016/[Link].2019.04.345. Retrieved from
[Link]
[Link]/science/article/pii/S2212827119309990
La Paz, A., & Vásquez, J. (2019). The Knowledge Body of Requirement Engineering in IST
Innovations: An Ontological Analysis. Journal of technology management &
innovation, 14(4), 78-84. Retrieved from
[Link]
vid=1&sid=787acfe5-9791-4977-9005-e880f62d931f%40sdc-v-sessmgr02.
Pichler, B. R. (2020, November 11). The Product Roadmap and the Product Backlog.
Roman Pichler. [Link]
backlog/
Kashyap, S. (2021, April 27). Traditional vs Agile Project Management Method: Which One
is Right for Your Project?ProofHub. [Link]
vs-agile-project-management
Kamal, T., Zhang, Q., & Akbar, M. A. (2020). Toward successful agile requirements change
management process in global software development: a client–vendor analysis. IET
Software, 14(3), 265-274.
Villamizar, H., Kalinowski, M., Viana, M., & Fernández, D. M. (2018, August). A systematic mapping
study on security in agile requirements engineering. In 2018 44th Euromicro conference on
software engineering and advanced applications (SEAA) (pp. 454-461). IEEE.
8
Schön, E. M., Thomaschewski, J., & Escalona, M. J. (2017). Agile Requirements Engineering: A
systematic literature review. Computer Standards & Interfaces, 49, 79-91.
Knauss, E., Liebel, G., Schneider, K., Horkoff, J., & Kasauli, R. (2017, September). Quality
requirements in agile as a knowledge management problem: More than just-in-time. In 2017
IEEE 25th International Requirements Engineering Conference Workshops (REW) (pp. 427-
430). IEEE.
Ochodek, M., & Kopczyńska, S. (2018). Perceived importance of agile requirements engineering
practices–a survey. Journal of Systems and Software, 143, 29-43.
Schön, E. M., Winter, D., Escalona, M. J., & Thomaschewski, J. (2017, May). Key challenges in agile
requirements engineering. In International Conference on Agile Software Development (pp.
37-51). Springer, Cham.
Rasnacis, A., & Berzisa, S. (2017). Method for adaptation and implementation of agile project
management methodology. Procedia Computer Science, 104, 43-50.
Saher, N., Baharom, F., & Ghazali, O. (2017, November). Requirement change taxonomy and
categorization in agile software development. In 2017 6th International Conference on
Electrical Engineering and Informatics (ICEEI) (pp. 1-6). IEEE.
Alam, S., Nazir, S., Asim, S., & Amr, D. (2017). Impact and challenges of requirement engineering in
agile methodologies: A systematic review. International Journal of Advanced Computer
Science and Applications, 8(4), 411-420.
Jia, J., Yang, X., Zhang, R., & Liu, X. (2019). Understanding software developers' cognition in agile
requirements engineering. Science of Computer Programming, 178, 1-19.
Wagner, S., Méndez-Fernández, D., Kalinowski, M., & Felderer, M. (2018). Agile requirements
engineering in practice: Status quo and critical problems. CLEI Electronic Journal, 21(1), 15.
