Requirements Analysis
Summary
TLDR本视频讲座深入探讨了系统设计与实施中的需求工程过程,包括问题领域分析、需求获取、需求捕获、需求验证与需求沟通管理等关键步骤。强调了与客户有效沟通的重要性,并介绍了多种方法如访谈、焦点小组、原型制作等,以确保软件开发团队能够准确理解和实现客户的真实需求。同时,还讨论了需求工程的最佳实践,如优先级排序、原型开发和需求验证,以提高项目成功率和客户满意度。
Takeaways
- 🔍 需求工程过程是系统设计和实现的关键部分,包括问题分析、需求引出、需求捕获、需求验证和需求沟通管理。
- 🤝 与客户进行有效沟通对于理解他们的需求至关重要,可以通过访谈、数据分析、小组讨论等方法进行需求引出。
- 📊 问题分析是识别客户实际问题的过程,有助于找到合适的软件解决方案。
- 📝 需求捕获涉及使用用例等工具来详细描述系统应执行的功能和过程。
- 🔎 需求验证确保需求的完整性、一致性和可追溯性,以及系统是否能够解决预定的问题。
- 📋 需求沟通和管理要求有良好的文档记录,包括创建正式的系统需求规格说明书,并采用版本控制策略。
- 🌟 成功的需求工程过程包括域分析、模型开发、原型制作和反馈循环,以确保系统满足客户的实际需求。
- 💡 通过故事讲述、情境模拟和原型展示等非正式方法,可以更好地理解客户的真实情况和需求。
- 🔄 在需求分析中,要考虑不同的情景,包括正常、异常和失败条件,以确保系统的健壮性。
- 👥 涉及多方利益相关者时,应组织焦点小组讨论或会议,以收集和理解多样化的需求。
- 📈 进行需求分析时,应优先考虑需求,分配项目资源,并使用最佳实践来提高规格说明书的质量。
Q & A
需求工程过程包括哪些主要活动?
-需求工程过程主要包括问题领域分析、需求引出、需求捕获、需求验证和需求沟通与管理。
问题领域分析的目的是什么?
-问题领域分析的目的是理解客户的真实问题,以便找到相关和适当的解决方案,为软件开发过程提供帮助。
需求引出是如何帮助软件开发团队的?
-需求引出通过访谈、数据分析等方法帮助团队识别和描述客户想要的功能,从而更好地理解客户的需求。
在需求捕获阶段,使用案例的作用是什么?
-使用案例通过简短的叙述描述系统应执行的过程、活动或功能,帮助确定系统应采用的流程。
需求验证的目的是什么?
-需求验证的目的是检查和确保需求的正确性、完整性、一致性,并确保系统能够解决预定的问题。
需求沟通与管理中,文档的作用是什么?
-文档在需求沟通与管理中的作用是记录需求,确保所有相关方都能访问和理解需求,同时便于需求的追踪和管理。
在需求工程中,如何识别和处理异常情况?
-通过分析不同用例的条件,识别正常、异常和失败场景,并为每种情况制定相应的处理策略。
为什么需求工程过程中的原型开发是一个好的实践?
-原型开发允许客户和团队直观地体验系统,提供反馈,从而在早期阶段发现并改进需求。
需求工程中的最佳实践包括哪些方面?
-最佳实践包括涉及客户和用户、识别所有可能的需求来源、分配技能娴熟的项目管理人员和团队成员、提供规格说明书模板和例子以及优先级需求。
如何确保需求的可追踪性?
-通过建立追踪性矩阵,确保需求与工作产品之间的链接清晰,并在项目过程中维护这些链接。
需求工程过程中,版本控制策略的重要性体现在哪里?
-版本控制策略确保需求文档的更新和变更得到有效管理,便于团队成员和客户了解当前使用的是哪个版本。
Outlines
🔍 需求工程过程概述
本段介绍了需求工程过程的重要性,它是系统设计和实现课程的一部分。需求工程过程包括问题领域分析、需求引出、需求捕获、需求验证和需求沟通与管理。这些活动、程序和系统分析师或软件开发团队的主要关注点是为了收集有助于系统设计的信息。特别强调了理解客户的真实问题对于软件开发过程的重要性,并且问题领域分析与需求分析紧密相关。
🤝 需求引出与沟通
这一部分讨论了需求引出的过程,即帮助人们识别和描述他们想要的东西。这包括与客户的沟通,如面试、数据分析、团队建设、焦点小组讨论、头脑风暴和网络搜索。还提到了将客户的需求和故事转化为技术文档的过程,以及如何将这些非技术性的语言转换为系统设计所需的对象、动词、形容词和流程。
📝 需求捕获方法
本段详细介绍了需求捕获的方法,特别是用例的使用。用例是描述系统应执行的过程或功能的短叙述。用例应该从动词开始,表示功能或关系,而不是对象。用例在不同抽象级别上出现,包括宏观层面和微观层面。此外,还讨论了用例的不同场景,包括正常场景、异常场景和失败场景,以及如何在需求分析中发现这些场景。
🚀 需求工程最佳实践
这一部分强调了需求工程中的最佳实践,包括涉及客户和用户的参与、识别所有可能的需求来源、分配熟练的项目管理人员和团队成员、提供规格模板和例子以及优先考虑需求。这些实践有助于提高规格质量,维持与利益相关者的良好关系,并更好地满足客户需求。
🔗 需求验证与沟通管理
本段讨论了需求验证的重要性,包括检查内部和外部需求的一致性、完整性、可追溯性和正确性。需求沟通和管理部分强调了记录需求、创建正式的系统需求规格说明、建立需求追溯标准和使用版本控制政策的重要性。这些步骤有助于确保需求的清晰传达和有效管理。
Mindmap
Keywords
💡需求工程
💡问题领域分析
💡需求获取
💡用例
💡功能需求
💡非功能需求
💡场景
💡需求验证
💡需求管理
💡最佳实践
Highlights
需求工程过程是系统设计和实施的关键部分,包括问题分析、需求获取、需求捕获、需求验证和需求沟通与管理。
问题领域分析有助于软件开发过程,通过理解客户的真实问题来找到相关和适当的解决方案。
需求获取是帮助人们识别和描述他们想要的东西的过程,这通常涉及访谈和数据分析。
需求捕获可以通过用例来完成,用例是描述系统应执行的功能或过程的简短叙述。
用例应该从宏观层面到微观层面不同抽象级别进行分析,关注企业的功能需求。
需求验证是检查需求是否正确无误的重要任务,包括识别缺陷、问题或其他缺陷。
需求沟通和管理涉及记录需求、创建正式的系统需求规格说明书,并建立需求追踪的标准。
需求工程过程中,原型开发是连接软件开发者和客户的好方法,可以提供实际使用体验。
需求工程的成功实践包括涉及客户和用户、分配适当的项目资源、提供规格模板和例子以及优先考虑需求。
需求分析和工程中的一个挑战是将客户的故事和技术文档转换,需要识别相关的对象、动词、形容词等。
在需求获取过程中,需要识别和描述客户想要的新系统,这可能涉及小组促进、联合应用开发和焦点小组讨论。
需求工程过程中,需求假设是对未来可能发生的情况的预测,需要通过系统开发进行验证。
在处理遗留系统时,需求获取应关注操作问题、变更和识别政治及其他难以解决的问题。
需求工程的一个关键活动是识别和记录客户的个人故事,这些故事有助于理解客户的实际生活情况。
在需求分析中,应该识别和记录不同的用例和场景,包括正常情况、异常情况和失败情况。
需求工程过程中,最佳实践包括优先考虑需求、开发补充模型和原型、维护可追溯性矩阵以及进行同行审查。
需求工程的成功实践还包括需求质量保证,确保需求的一致性、完整性和可追溯性。
Transcripts
foreign
and in this video
I will be discussing requirements
Engineering Process
and this is a part of our lecture in
systems design and implementation
or basic
base and advanced systems design and
implementation
so this is primarily like second or
third part of our lecture and this is
all about requirements Engineering
Process which is one of the crucial part
of systems
foreign
situation of your customers
so
the requirements Engineering Process is
composed of problem domain analysis
requirements elicitation
requirements capture
requirements validation and requirements
communication and management so all of
this faces comprises all of the
activities
procedures and
that a systems analyst or group of
software development team has to
concentrate primarily to be able to
gather information that will help in the
design of
systems being developed
analysis requirements solicitation
requirements capture requirements
validation
and then requirements communication and
management and we will try to discuss
all of them one by one
so let's first look into problem domain
analysis understanding the real problem
with your customer
is a big help to the software
development process it's because in that
way we will be able to First find a
relevant and appropriate solution of
assertive
department or
so the problem domain analysis is also
related to your requirements analysis
it's because
the problem itself will tell you what
are the requirements which has to be
collected to be understood and to be
implemented to be able to have a good
software design
which is a foundation for requirements
and visitation capture analysis and
Designs we all know we have to fully
understand the real problem and in fact
during the requirements analysis phase
that is also
will discover
accidentally or intentionally some
problems which are related to your
software development and also some
problems which might not be related to
your software development
so what is requirement elicitation so in
our
set of materials there is a paper
wherein
um
we are required to do some paper
analysis and that is requirements
exhibition it's a paper published and a
referee and published paper on
requirements solicitation
and it deals with
what is really the relationship okay
between customers and the software
developer so we fully need to understand
how to properly communicate between our
customers so as a software developer
what are really the the relationship
so that comprises
of some of the important discussions on
requirement in sedation
so it is a process in which people will
help you are going to help people
identify and describe what they want
so that's why we need to have some
source of interview and also some data
analysis sometimes you need to go to the
um
to the company to be able to help them
understand
what are really the problem that exists
in the company because sometimes they
really don't know what are their
problems okay they just need
um to make their life easier and they
want maybe something new in their
day-to-day work but to specifically
identify
uh micro problems I think that is not I
mean your your
people in the company is not capable of
doing that
so that's why you should have uh you
should link okay your systems
Development Goal to the system or
Enterprise go
you can do all of this by doing all
these things okay so these are some of
the processes that uh
you can perform to be able to identify
and describe what your customers want
the new system so that's group
facilitation so it can be judged or
joint application development so this is
a process where in
developing the system to get
to give K so it means you're going to
the company sometimes you're doing some
interview or doing some consultation
from time to time
and then another is assembly or jigsaw
group of its Enterprise participants
that represents diverse Enterprise
stakeholders or Community interests so
sometimes you need to do some focus
group discussions or meetings with the
whole group or small groups to be able
to fully understand their individually
okay that's why you need to do some
individual interview or group interview
and then brainstorming brainstorming and
idea generation so your customers can
also help you the design
um not because they are good in systems
design but of course they will help you
to fully identify
um the things that they want to put into
the system or the things that they don't
want to put or they don't want to see on
the system and then search the web and
demonstrate similar system so I think
this is one of the easiest way to
communicate your customer which is like
showing a system which has been used by
other companies
or like
um let's say you're going to develop a
particular database or an Erp for a
certain company so it's better for them
for you to show them what is an ARB or
show an a real life system or a live PRP
being used by another
can describe and explain to them how
this is being used and ask them if that
is really the one that they want to
develop for your system or the one that
they want to use
so we can say that requirements
again as a stories
personal stories
um personal experiences of your
customers or clients on their milestones
and their jobs
it's really even harder if you're going
to develop a system that you start from
the scratch like from
semi computerized to a fully automated
Erp so that's going to be quite
challenging and that's why you need to
listen to their stories okay so you have
to carefully Chuck down a record
identify
related objects verbs as relations
adjectives as attributes recipes or how
to's as processes storyline as workflow
so that is how we convert okay those
layman's terms that your
here your clients have told you as their
personal story you have to convert them
into
technical
document as I can say like stories
so you can convert the different nouns
as objects and the verbs as the
relationship
the adjectives as the attributes for
your database and recipes like
the processes that's being done or how
to's and convert them to your workflow
so basically it's
understanding the real life situation of
client
converting them
in the biograms okay or those diagrams
that we use in systems design okay and
stories can also be organized
through storyboard
okay
and then there is also some informal
method just like post it on the wall
and also prototypes or mock-ups as
interlinked connection of web and pages
and we can also say that requirements
are also hypothesis
like for example you you didn't meet yet
people in the company but you know
they have a hypothesis like okay this is
what is supposed to happen this is
supposed to be the the process of
enrollment just like in another
University
okay but you do you have to do some
verification because not all for example
in the case of universities not all
universities have the same process
they like State University might have
might have some similarity but even if
they are all state universities uh they
are really not the same and the same
with private universities
so you have to do some verification
through system development and validate
okay by implementation
and then illiciting requirements when
enhancing Legacy systems
are these advocating requirements
for one focus on operational problem
terrible change
seek to identify political and other
unsolvable problems
under eliciting requirements
like you have to determine the cop if
customers or users recognize the problem
and solution opportunity okay and then
you need to conduct survey and
assessment of current vendor or
competitor
which are doing the same product
and also Advocate moderation and
feasibility analysis you have to assess
if
my the plan that you're going to do for
a certain company could be visible in
many ways like for example budget and
okay so let's discuss requirements
capture how are you going to capture the
exact requirements so this is
particularly the requirements for
systems development or the requirements
which are supposed to be implemented in
your system okay or people specific
Ally so let's discuss use case
what is the use case so these are short
narratives describing some processes
activity or function that identifies
system
an Enterprise System should perform
okay so you need to identify what are
the processes that should take place
and what are the processes that the
system should adopt
okay so use cases lead with a verb or
action word that denotes functions or
relations but not object
okay
so use cases we can say determining
of different
processes
that should be done
okay so you have to look for the verb
that's involved in
a certain
process in a particular organization
okay and then cases will Arise at
different levels of abstraction like for
example in top level so it's like a
macro picture
while the mid-level and groupings are
low level so we can say that's the micro
micro means the very specific processes
so you have to look from top to bottom
okay from the macro level to the micro
level
cases should focus on functional
requirements of the Enterprise okay so
what are the functional requirements
so what are the functions that needs to
be done to be able to complete complete
the whole workflow
how about then functional requirements
so these are for example these are
reliability
Focus news user friendly okay those are
non-functional okay it means you still
need that I mean we still need to to
find it in your system but those are
things that cannot really be identified
should happen in a particular
color okay and that's why we say they
are not part of the use case
and then when you identify the different
processes or use cases then another
thing that we need to do is
see the different scenarios for issues
okay there are normal scenario or
typical scenario
but there are also exceptional scenario
and there are also failure scenarios
so there are different scenario in
particular use case
in a particular use case
um
student requests for example I'm talking
about your
environment system
so one of the use cases uh students
request
request that students are doing in a
particular student portal for example
adding subjects
changing adding changing subjects
requests for tutorial what else for
example request for Activation in your
system
what else
enlistment okay so there are a lot of
scenario and in each scenario there are
different conditions
okay I'm in use case I mean in different
use cases there are different conditions
okay and that is like normal so normal
typical scenario or scenario which
follows
the rule or the steps okay okay for
example one student is going to enlist
so
um let's say the the default process is
like if you click enlistment he will see
um all the subjects
that he needs
needs in accordance to his year level
and to his
um
program let's say ID so if I'm second
year ID and it is second trimester or
third trimester so if I click enlist I
will see all the subjects enrolled for
let's say I'm second year for second
year
third trimester in vsip so there are six
subjects but what are the exceptional
conditions okay for example you have to
discover something like this okay which
you need to do in the requirements
analysis what if the student is not a
regular student
belong in a blog section
so it means
irregular students
and then when he saw all the six
subjects he said I think I already
enrolled this one I think it115 I
already took that I finished that so why
is it still displayed here
so if that happens the system needs
another
another maybe another module okay or
another
tab in your system which will ask the
students are you a regular or a regular
student
or maybe
uh
another way or another button to request
for advisement
okay
so it means that particular student
needs his program chair to advise him
for subjects to be involved because the
subjects displayed in the portal is not
appropriate for that student because
only
the regular students can enroll those
which are in the quarter so that's
exceptional condition
so you have
to try to discover what are the
exception exceptional scenarios in a
particular use case
what about failure conditions so how to
handle events or data that should be
detected and prevented and how the
system Enterprise should respond to user
to usage problems that end user
so this is very common among the use of
Erp
okay for example
um
in my experience when we developed that
system we put some validation for
example you cannot enroll if you have
not submitted
your if you have that finished your
psychological interview or it means the
guidance interview okay I have not
submitted that I have not done my
guidance interview
I was first here and now I'm second here
okay
so when I enrolled in second trimester I
cannot I cannot see
and there is an error message there
you are tagged okay by the guidance
counselor and you cannot enlist
because you are tagged to First
schedule a certain guidance counselor
interview
okay
so that's one kind of failure conditions
and
what is our in our experience students
can handle that because
of the system doesn't have anything
to to do with it because the system
doesn't tell the student how to solve
that problem
okay there's no interface there's no
button
telling the student if you have that or
if you want
okay if you want to clear this tagging
you have to click this button
okay there's no nothing like that
so that's one thing that should be
solved in the system and that's one
thing you have to see
and in the real life is students just
uh send email to any to just anyone they
don't know where to send email sometimes
they send email to their teacher
sometimes they send email to me
because my
my email address is posted in
PW
website
so that's why my email is flooded with
many
um
customer complaints but I'm not the one
to get that okay that was before
so that particular failure condition
should be
um
I mean you should be able to imagine
that okay you should be able to foresee
that okay
okay so I'm going to show you
um the best practices
so these are the best practices
okay
in your requirements analysis
okay
so you have to identify the different
Focus area like knowledge resources
processes
what are the Press what are the best
practices
so for example involve customers and
users
through requirements analysis and
identify cons and console all likely
sources of requirements
assign skilled projects managers and
team members
allocate 13 to 15 percent to 30 15 to 30
percent of total project effort
to re and provide specification
templates and examples and prioritize
requirements so it's a process name okay
and you can see here the cost of
introduction and cost of application and
the key benefits
so if you invoke customer and users to
re
you're going to have better
understanding of the real means so they
should be there identify and consult all
likely sources of requirements it
um
even if there is
a science skilled project managers and
team members for re so it means in your
team
there is one I mean one group of uh Team
or in a particular team there's one
group who is specialized in re
so you could expect more predictable
performance and allocate 50 to 30
percent of total project effort so it
maintained high quality specification
through the project
and then provide specification and
templates example so key benefit is
improve quality of specification and
also maintain good relationship with
stakeholders so it's better satisfy
customer needs if you can maintain good
relationship then your customer will be
able to be more open more open Intel in
their needs how about in the processes
prioritize requirements so the key
benefit is focus attention to the most
important customer
need process develop complementary
models together with prototypes
so it eliminates specification
ambiguities and consistencies and then
also maintain a traceability matrix
explain link between the requirements
and word products and another use peers
peer reviews scenarios and walkthroughs
to validate and verify requirements and
then more accurate specification and
higher customer
satisfaction so I have here another
diagram here this is a successful
requirements Engineering Process okay
it's because you know when we do
requirements analysis
most of software development have to
introduce new ways of doing things so
you are going to do business process for
engineering or you need to re-engineer
the way people in the company do their
job to shorten for example to shorten
the process or they make the process
more efficient so this is the diagram
showing the
successful requirements Engineering
Process
so you have here the application domain
and in here the compilation of
specification
so the domain analysis here is your
domain knowledge
such as develop basic and advanced
models and then develop prototypes so as
you can see in here prototype is really
a good one of the good practices in
requirements engineering
so your application domain here has your
system artifacts and Source materials
developing your model so you need to be
a review with your customers and your
your team and then get the feedback of
your customers and then compile all
their
comments and suggestions and then
scenario walkthrough in which it's
really important to have a prototype so
that you can see how they use it how
they feel to use it and the personal
experiences and real life experiences in
using the Prototype really pays value
development and then develop prototype
and mock-ups okay
so here is the paper
so here's the paper that I uploaded
so this is from elsevier information and
software technology Journal
and this is our requirements engineering
making connection between software and
develop software developer
and so this paper
is quite old but I think this is like a
leadership paper image it gives you many
real life experiences on how you can
connect us us as a team to your clients
okay
here
it investigates key players
and the rules in the company and along
with existing methods and obstacles and
requirements solicitation so
you are going to read here the different
Key activities and methods for gathering
information
so you're going to see some examples on
how to gather information as well as
different approaches and ideas for
improving transfer and record of
information
okay and this paper can also be your
guideline okay for engineering for
re-engineering a particular systems
so please read on this as part of our uh
lecture because I'm going to ask you to
submit a PowerPoint presentation for
this paper so
it's a lecture for this
let's continue
so we have to do again another part of
our requirements analysis and
Engineering is requirements validation
okay how we're going to test the
requirements so this is a part of uh
important tasks in requirements analysis
so you have to check
and do that and discussion of system
requirements inspectors take on
different roles and reviewing inspectors
in one role post questions that either
sound to be answered by available system
requirements or from other inspectors
acting in other roles and then gaps have
to identify the gaps and answered
questions or other defects and
requirement specification deliverables
so that's one of the most important in
deliverables so you have to identify
who participated what time
we ask what defects are unexpected
findings were found
and what are the opinions and what
actions are needed to improve the
quality
how about requirements analysis
requirements quality assurance or in
other words requirements verification
yeah
traceability and correctness okay
consistency things are named a
referenced in a unique predictable and
ambiguous model
so complete use cases are interrelated
of course each has multiple scenarios
and identify the different scenarios
everything name or reference is
accounted for it
least one case use case or scenario and
then traceability everything in which
picture is accounted for which use case
and correct is at is everything in order
so you have to check the internal and
external
so internal requirements are cons it
should be consistent complete traceable
and the system appears to solve the
problem it is supposed to
and it should be obtainable about
external the system this does what it is
supposed to and this is nothing more or
less okay
now how about requirements communication
and management how are you going to
communicate that among your groups and
among the clients
so you have to document the requirements
okay you have to have
a thing on file okay so create a formal
system requirement specification and
that's one you have to submit
establish criteria for requirement
traceability be able to
collect hyperlink you can do that and
browse analysis design implementation
and other life cycle documents to the
originating system requirements so this
is part of your documentation manage and
start manage the storage and evolution
of system require
both system require
D in ways that they can be remotely
browsed and update via Version Control
policy okay so I tell you I'm one of the
challenging part is that you need to
have this Version Control policy because
of so many versions that you updated you
have to make it create a very clear to
understand of what version is currently
okay because this is something that you
are going to use to communicate with
your clients so you have to do
you have to have a good technical report
okay
so I'm not going to make it an
assignment because
um you are going to implement those
things that we have discussed those are
the different
um insights that you can use to be able
to do your systems design and Analysis
and that is why
um in the next activities in
case and you already have your grouping
I hope that by next week you can present
um your paper or I mean you can present
your title
and then also
um do some planning for your
requirements analysis and then submit
your
meteor so these are all uploaded in our
portal in our Google Classroom so thank
you very much for listening to our video
and I hope that you were able to
um
get some good ideas
with project to be able to create a
group
that's all for this video
thank you very much
Ver Más Videos Relacionados
Requirement Specification vs User Stories
Lean vs Agile vs Waterfall | What is Lean | Difference between Waterfall and Agile | Intellipaat
Supply Chain Modelling: Multi Objective Robust Optimization Model for Facility Layout Design
Webinar - Supply Chain Optimization: A Robust Supply That Minimizes Costs
Networking for GenAI Training and Inference Clusters | Jongsoo Park & Petr Lapukhov
Keyword Research Tutorial: From Start to Finish
5.0 / 5 (0 votes)