听了一节需求评审会

作者初次参与需求评审会议,分享了对于需求评审的理解与反思,认为需求评审类似于寻找软件BUG的过程,并强调需求最终由客户确认。通过这次经历,作者认识到不应将事物过度复杂化,并意识到了之前工作中存在的问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

 今天第一次参加需求评审,我原以为需求评审很高深的东西,其实也就是纠正错误和模式方面的错误,就跟找软件的BUG是一样的。需求的验收还是由客户说了算了。
以后多参加几次就好了,
其实有时候我把任何事情都想得太复杂了,就像这次的需求评审,把事情想得复杂有不好的地方:
一是自己做的对不对,表示怀疑,认为这东西太简单了,好像不是那样。
二是产生浮燥,对任何事情都不是那么的认真,这次我才发现,我以前做的东西都是不负责任的表现。我错了。

### 用例图在论文中的合适位置 在撰写IT文档或学术论文时,用例图通常被放置于系统需求分析部分或者设计阶段的部分。这是因为用例图主要用于描述系统的功能性需求,帮助读者理解系统的目标用户及其操作流程。 #### 需求分析章节 如果论文的重点在于阐述系统的需求,则可以将用例图置于需求分析章节中。这一节的主要目的是明确系统的边界、参与者以及各个功能模块的关系[^1]。通过用例图,作者能够清晰地向评审者展示“谁会使用该系统”以及“这些使用者希望完成哪些任务”。因此,这部分的内容应围绕如何识别并定义系统的关键角色展开讨论。 #### 设计方案章节 另一方面,当研究更侧重于具体的设计实现时,也可以把用例图安排到设计方案章节里去。此时它作为连接高层次概念模型与低层次技术细节之间桥梁的角色出现。在这里不仅需要介绍基本的功能划分情况,还需要进一步探讨不同子系统间协作机制等问题[^2]。 无论是在哪个具体的章节呈现出来,都应该确保其紧随相关背景信息之后,并且前面已经充分论述过为何选择当前架构形式等内容;同时也要注意前后逻辑连贯性,使得整篇文章条理分明易于理解。 ```python # 示例Python代码片段:生成简单的UML用例图数据结构表示 class Actor: def __init__(self, name): self.name = name class UseCase: def __init__(self, description): self.description = description actor_user = Actor("User") use_case_login = UseCase("Login System") print(f"{actor_user.name} interacts with {use_case_login.description}") ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值