Requirements Analysis

Summary

本视频讲座深入探讨了系统设计与实施中的需求工程过程，包括问题领域分析、需求获取、需求捕获、需求验证与需求沟通管理等关键步骤。强调了与客户有效沟通的重要性，并介绍了多种方法如访谈、焦点小组、原型制作等，以确保软件开发团队能够准确理解和实现客户的真实需求。同时，还讨论了需求工程的最佳实践，如优先级排序、原型开发和需求验证，以提高项目成功率和客户满意度。

Takeaways

• 🔍 需求工程过程是系统设计和实现的关键部分，包括问题分析、需求引出、需求捕获、需求验证和需求沟通管理。
• 🤝 与客户进行有效沟通对于理解他们的需求至关重要，可以通过访谈、数据分析、小组讨论等方法进行需求引出。
• 📊 问题分析是识别客户实际问题的过程，有助于找到合适的软件解决方案。
• 📝 需求捕获涉及使用用例等工具来详细描述系统应执行的功能和过程。
• 🔎 需求验证确保需求的完整性、一致性和可追溯性，以及系统是否能够解决预定的问题。
• 📋 需求沟通和管理要求有良好的文档记录，包括创建正式的系统需求规格说明书，并采用版本控制策略。
• 🌟 成功的需求工程过程包括域分析、模型开发、原型制作和反馈循环，以确保系统满足客户的实际需求。
• 💡 通过故事讲述、情境模拟和原型展示等非正式方法，可以更好地理解客户的真实情况和需求。
• 🔄 在需求分析中，要考虑不同的情景，包括正常、异常和失败条件，以确保系统的健壮性。
• 👥 涉及多方利益相关者时，应组织焦点小组讨论或会议，以收集和理解多样化的需求。
• 📈 进行需求分析时，应优先考虑需求，分配项目资源，并使用最佳实践来提高规格说明书的质量。

Q & A

需求工程过程包括哪些主要活动？

需求工程过程主要包括问题领域分析、需求引出、需求捕获、需求验证和需求沟通与管理。

问题领域分析的目的是什么？

问题领域分析的目的是理解客户的真实问题，以便找到相关和适当的解决方案，为软件开发过程提供帮助。

需求引出是如何帮助软件开发团队的？

需求引出通过访谈、数据分析等方法帮助团队识别和描述客户想要的功能，从而更好地理解客户的需求。

在需求捕获阶段，使用案例的作用是什么？

使用案例通过简短的叙述描述系统应执行的过程、活动或功能，帮助确定系统应采用的流程。

需求验证的目的是什么？

需求验证的目的是检查和确保需求的正确性、完整性、一致性，并确保系统能够解决预定的问题。

需求沟通与管理中，文档的作用是什么？

文档在需求沟通与管理中的作用是记录需求，确保所有相关方都能访问和理解需求，同时便于需求的追踪和管理。

在需求工程中，如何识别和处理异常情况？

通过分析不同用例的条件，识别正常、异常和失败场景，并为每种情况制定相应的处理策略。

为什么需求工程过程中的原型开发是一个好的实践？

原型开发允许客户和团队直观地体验系统，提供反馈，从而在早期阶段发现并改进需求。

需求工程中的最佳实践包括哪些方面？

最佳实践包括涉及客户和用户、识别所有可能的需求来源、分配技能娴熟的项目管理人员和团队成员、提供规格说明书模板和例子以及优先级需求。

如何确保需求的可追踪性？

通过建立追踪性矩阵，确保需求与工作产品之间的链接清晰，并在项目过程中维护这些链接。

需求工程过程中，版本控制策略的重要性体现在哪里？

版本控制策略确保需求文档的更新和变更得到有效管理，便于团队成员和客户了解当前使用的是哪个版本。

Outlines

00:00

🔍 需求工程过程概述

本段介绍了需求工程过程的重要性，它是系统设计和实现课程的一部分。需求工程过程包括问题领域分析、需求引出、需求捕获、需求验证和需求沟通与管理。这些活动、程序和系统分析师或软件开发团队的主要关注点是为了收集有助于系统设计的信息。特别强调了理解客户的真实问题对于软件开发过程的重要性，并且问题领域分析与需求分析紧密相关。

05:02

🤝 需求引出与沟通

这一部分讨论了需求引出的过程，即帮助人们识别和描述他们想要的东西。这包括与客户的沟通，如面试、数据分析、团队建设、焦点小组讨论、头脑风暴和网络搜索。还提到了将客户的需求和故事转化为技术文档的过程，以及如何将这些非技术性的语言转换为系统设计所需的对象、动词、形容词和流程。

10:03

📝 需求捕获方法

本段详细介绍了需求捕获的方法，特别是用例的使用。用例是描述系统应执行的过程或功能的短叙述。用例应该从动词开始，表示功能或关系，而不是对象。用例在不同抽象级别上出现，包括宏观层面和微观层面。此外，还讨论了用例的不同场景，包括正常场景、异常场景和失败场景，以及如何在需求分析中发现这些场景。

15:05

🚀 需求工程最佳实践

这一部分强调了需求工程中的最佳实践，包括涉及客户和用户的参与、识别所有可能的需求来源、分配熟练的项目管理人员和团队成员、提供规格模板和例子以及优先考虑需求。这些实践有助于提高规格质量，维持与利益相关者的良好关系，并更好地满足客户需求。

20:08

🔗 需求验证与沟通管理

本段讨论了需求验证的重要性，包括检查内部和外部需求的一致性、完整性、可追溯性和正确性。需求沟通和管理部分强调了记录需求、创建正式的系统需求规格说明、建立需求追溯标准和使用版本控制政策的重要性。这些步骤有助于确保需求的清晰传达和有效管理。

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