易于使用的人工智能_需求分析：如何使用这种易于启动的方法+一个案例研究...-CSDN博客

易于使用的人工智能

by Turgay Çelik

由TurgayÇelik

需求分析：如何使用这种易于启动的方法+一个案例研究 (Requirement Analysis: how to use this startup-friendly approach + a case study)

In our previous blog posts, we explained why we decided to develop the Badges App and how we evaluated the feasibility of our idea at OpsGenie:

在之前的博客文章中，我们解释了为什么决定开发Badges App以及我们如何在OpsGenie中评估我们的想法的可行性：

Since we found that our idea is worth developing, the next step is analyzing the requirements.

由于我们发现我们的想法值得发展，因此下一步是分析需求。

Requirement analysis — a very well studied area of software engineering — is the process of determining user expectations for a product, or briefly defining the product scope. There are tons of available resources on requirements analysis methodologies, characteristics of good requirements and tracing requirements. Instead of repeating the literature, we are going to summarize the critical points in a startup thinking way.

需求分析是一个非常深入的软件工程领域，是确定用户对产品的期望或简要定义产品范围的过程。关于需求分析方法，良好需求的特征和跟踪需求，有大量可用资源。与其重复文献，不如以一种新的思维方式来总结关键点。

We know, startup guys generally don’t like terms like “process”, “proof of concept”, “requirements”, “scope”, “schedule”, “design”, “documentation” or “maintainability”. Generally they are impatient and they just want to code and release. We accept that agility is vital in our world and we have to try, fail and recover fast. But benefiting from the heritage of the software world will help us on the way to success. The key point is keeping it agile.

我们知道，刚开始的家伙通常不喜欢“过程”，“概念证明”，“需求”，“范围”，“计划”，“设计”，“文档”或“可维护性”之类的术语。通常，他们不耐烦，只想编码和发布。我们接受敏捷性对我们的世界至关重要，我们必须尝试，失败和快速恢复。但是受益于软件世界的遗产将帮助我们迈向成功之路。关键是保持敏捷。

Following a process is not an objective, it is a tool that helps us achieve our goals. So, let’s see how we can adopt classical approaches to our world in the context of requirements management.

遵循流程不是目标，而是帮助我们实现目标的工具。因此，让我们看看如何在需求管理的背景下对我们的世界采用经典方法。

The Project Management Triangle is a model of the constraints of software management. Despite the fact that it is an old concept from the 1950's, I think it is still relevant.

项目管理三角形是软件管理约束的模型。尽管它是1950年代的旧概念，但我认为它仍然有意义。

In summary, project management triangle says that the quality of work is constrained by the project’s budget, deadlines and features. There is a trade-off among these three constraints to achieve the necessary project quality. So we can say that software development is a multi-objective optimization problem.

总而言之，项目管理三角表示工作质量受到项目预算，期限和功能的限制 。为了获得必要的项目质量，需要在这三个约束之间进行权衡。因此可以说软件开发是一个多目标优化问题。

We don’t like to constrain ourselves by classical approaches, so let’s adapt the old Project Management Triangle to the new startup world. Recall the Startup Success Factors that we mentioned at Feasibility Analysis post.

我们不喜欢用经典的方法来约束自己，所以让我们将旧的项目管理三角形适应新的创业世界。回想一下我们在可行性分析后提到的启动成功因素。

Here is how we map these success factors to the classical project management triangle:

这是我们将这些成功因素映射到经典项目管理三角的方法：

As shown in the table above, all startup success factors relate to various project management triangle constraints. Since these three constraints are in a trade-off, we can say that keeping the scope neat is vital for the success of a startup.

如上表所示，所有启动成功因素都与各种项目管理三角约束有关。由于这三个约束是折衷的，所以可以说保持范围整洁对于启动成功至关重要。

To define a neat scope, we have to perform a good requirement analysis before starting the development. Please note that this does not mean we are going to perform a fully detailed requirement analysis just like defined in waterfall process. We are going to do it in agile way.

为了定义一个整洁的范围，我们必须在开始开发之前进行良好的需求分析。请注意，这并不意味着我们将像瀑布过程中定义的那样执行全面详细的需求分析。我们将以敏捷的方式做到这一点。

需求分析技巧 (Tips for Requirement Analysis)

In this section, we will provide important tips that you should keep in mind:

在本节中，我们将提供您应该记住的重要提示：

深入检查替代/同类产品 (Inspect Alternative/Similar Products In Depth)

As always, don’t reinvent the wheel. Check what others do to meet your objectives. Even you may end up realizing that your product does not seem to have business impact that you were thinking before.

与往常一样，不要重新发明轮子。检查其他人为实现您的目标所做的事情。甚至您可能最终也意识到，您的产品似乎并没有像您以前想的那样对业务产生影响。

This is a good sign to pivot your idea. It may seem like a failure, but remember, we have to fail as fast as possible.

这是改变您的想法的好兆头。这似乎是一个失败，但请记住， 我们必须尽快失败 。

记录您的要求 (Document your requirements)

You don’t have to use a requirements management tool such as IBM Rational DOORS. But a short, bulleted requirements document will help negotiate with the stakeholders.

您不必使用诸如IBM Rational DOORS之类的需求管理工具。但是，简短的项目符号需求文档将有助于与利益相关者进行谈判。

让您的(潜在)客户保持联系 (Keep Your (Potential) Customers In the Loop)

I think this is one of the most important things about requirements development. A capability that you think that is killer may not make sense to the customers.

我认为这是需求开发中最重要的事情之一。您认为致命的功能对客户而言可能没有意义。

To keep your potential customers in the loop, you have to follow an iterative approach. You can do this by shipping an initial version of your product — Minimum Viable Product (MVP) — and evolving it according to customer feedback.

为了使您的潜在客户保持联系，您必须采用迭代方法。为此，您可以交付产品的初始版本-最低可行产品(MVP)-并根据客户反馈对其进行改进。

For example, Amazon Web Services team utilizes this approach frequently. They ship a service with minimum capabilities and evolve it based on customer feedback.

例如，Amazon Web Services团队经常使用此方法。他们以最低的功能交付服务，并根据客户的反馈进行发展。

Another approach is to develop mock applications that just provide a dummy user interface (UI) to help potential customer to understand the product features and give feedback. You can use products like InvisionApp to produce these mocks.

另一种方法是开发仅提供虚拟用户界面(UI)的模拟应用程序，以帮助潜在客户了解产品功能并提供反馈。您可以使用InvisionApp之类的产品来生成这些模拟。

需求管理是一个连续的过程 (Requirements Management is a Continuous Process)

You don’t have to spend months for requirements analysis at the beginning of a project, and please don’t — it is not the agile way.

在项目开始时，您不必花费数月的时间进行需求分析，请不要这样做-这不是敏捷方法。

At the beginning, your objective is to define boundaries of the system, negotiate with the team and other stakeholders, and prepare the definition of the Minimum Viable Product. The requirements should be detailed or can even evolve during iterations of development.

首先，您的目标是定义系统的边界，与团队和其他利益相关者进行谈判并准备最小可行产品的定义。需求应该是详尽的，甚至可以在开发的迭代过程中不断发展。

分组您的要求 (Group your requirements)

After you create a list all of your requirements, group them (divide and conquer) to form sets of related features. Grouping requirements to feature groups will ease your life during development phase and even it can help you to define bounded contexts, microservice architectures, and so on.

创建所有需求列表之后，将它们分组(分而治之)以形成一组相关功能。将需求分组到功能组将简化您在开发阶段的工作，甚至可以帮助您定义有限的上下文，微服务体系结构等。

考虑UX (Think About UX)

It is not necessary to say that User Experience (UX) is a very important factor in the success of a product anymore; today it is so obvious. But we have to still remind that User Experience is not just about fancy User Interfaces.

不必说用户体验(UX)成为产品成功的一个非常重要的因素；今天是如此明显。但是，我们仍然必须提醒用户体验不仅仅是花哨的用户界面。

As the name implies, it is all about the “experience” and it is hard to improve a system’s UX after it is developed.

顾名思义，这一切都与“体验”有关，开发系统后很难改进其用户体验。

Think about UX starting from requirements analysis, it could even be a motivation during the feasibility analysis phase to develop a new product if available alternatives in the market lack good UX.

从需求分析开始考虑用户体验，如果市场上的可用替代品缺乏好的用户体验，那么甚至可能是在可行性分析阶段开发新产品的动机。

User Experience affects the business requirements. For example, if you are developing an e-commerce application, designing a fast responding customer support system is about improving the User Experience.

用户体验会影响业务需求。例如，如果您正在开发电子商务应用程序，那么设计一个快速响应的客户支持系统就是要改善用户体验。

尽可能不了解实施技术 (Be Agnostic of Implementation Technologies As Much As Possible)

Of course this is not applicable if you are developing an infrastructure or a library for a specific technology :)

当然，如果您正在为特定技术开发基础结构或库，则此方法不适用：)

Don’t fall into “If all you have is a hammer, everything looks like a nail” trap. Find new tools and utilities instead of limiting product capabilities to the technologies that you are familiar with or that you enjoy playing with.

不要陷入“如果只有锤子，一切看起来都像钉子”陷阱。查找新的工具和实用程序，而不是将产品功能限制为您熟悉或喜欢使用的技术。

In enterprise companies, requirements analysis is generally performed by non-software engineers who are generally known as business analysts or systems engineers. This separation has some disadvantages, especially in terms of transferring requirements to development teams, but I think it also has some advantages.

在企业公司中，需求分析通常由通常称为业务分析师或系统工程师的非软件工程师执行。这种分离有一些缺点，特别是在将需求转移到开发团队方面，但我认为它也有一些优点。

In my opinion, the biggest advantage of independent analysis teams is that they are agnostic of the technologies that will be used during development.

在我看来，独立分析团队的最大优势是他们对将在开发过程中使用的技术不可知。

But in the startup world, most probably as a team member (or even as a founder), you have to wear multiple hats: analyst, developer, hiring manager, or even more interesting roles that you were not imagining when you get in this path. So, if you are wearing the analyst hat at the moment, try to be agnostic of the technologies that you are planning to use during implementation.

但是在创业世界中，很可能作为团队成员(甚至是创始人)，您必须戴上多个帽子：分析师，开发人员，招聘经理，或者甚至更有趣的角色，而当您走上这条路时。因此，如果您现在戴着分析员的帽子，请不要理会计划在实施过程中使用的技术。

We consistently hear expressions like “but Spring Framework does not support …” and “This causes a lot of work on the front-end” during requirement analysis.

在需求分析过程中，我们始终听到诸如“但Spring Framework不支持…”和“这在前端导致大量工作”之类的表达。

Considering these kind of limitations at the start degrades the quality of the end product. Let’s define the ultimate capability and evolve it during development if necessary.

一开始考虑这些限制会降低最终产品的质量。让我们定义最终功能，并在必要时在开发过程中对其进行发展。

Ultimate capability is the final goal to reach, you can implement a more simple form of it when you start and evolve it in future versions. But knowing the point that we want to reach will help us to define our vision for the growth of the product.

最终功能是最终的目标，您可以在开始并在将来的版本中进行扩展时，以更简单的形式实现它。但是，知道我们要达到的目标将有助于我们确定产品增长的愿景。

For example, think about “pinch-to-zoom” capability of mobile phones. It seems like a trivial capability but it was a revolution when Steve Jobs first demonstrated it. If the designers of iPhone didn’t think out-of-the-box and stuck to the available technologies and methods, we would not have this great functionality today. We know that it is an exaggerated example, but the main point is, don’t let the technology you would like to use limit you, you can move to other technologies if this will help you to create a niche product.

例如，考虑一下手机的“缩小缩放”功能。这看似微不足道的功能，但这是史蒂夫·乔布斯(Steve Jobs)首次展示它时的一次革命。如果iPhone的设计师没有开箱即用的想法，而是坚持使用可用的技术和方法，那么今天我们就不会拥有如此强大的功能。我们知道这是一个夸张的示例，但要点是，不要让您想使用的技术限制您，可以使用其他技术来帮助您创建利基产品。

徽章应用程序的需求分析 (Requirements Analysis for Badges App)

We performed requirements analysis according to the practices that we summarized above:

我们根据上面总结的实践进行了需求分析：

We defined an initial set of requirements
我们定义了一组初始要求
We shared the requirements with our initial customer — The OpsGenie team — and updated the requirements according to the team’s comments.
我们与最初的客户OpsGenie团队共享了需求，并根据团队的评论更新了需求。
At OpsGenie, we use Atlassian’s JIRA for issue tracking. To track the requirements, we created an issue with “New Feature” type for each requirement in JIRA.
在OpsGenie，我们使用Atlassian的JIRA进行问题跟踪。为了跟踪需求，我们为JIRA中的每个需求创建了一个“新功能”类型的问题。
We grouped related requirements with JIRA Epics. Some of our epics are User Operations, Group Operations, Badge Operations, Endorsement and 3rd Party Tool Integration.
我们将相关需求与JIRA Epics进行了分组。我们的一些史诗是用户操作，组操作，徽章操作，背书和第三方工具集成。
In further steps of development, we created detailed issues for daily tasks, as Agile practices recommend. We linked each task with one or more requirements to keep traceability of development activities with requirements.
在进一步的开发步骤中，我们按照敏捷实践的建议为日常任务创建了详细的问题。我们将每个任务与一个或多个需求相关联，以保持开发活动与需求的可追溯性。
Each epic contains a set of requirements (such as a New Feature), Development Tasks, and Bugs.
每个史诗都包含一组要求(例如新功能)，开发任务和错误。

Want to follow our Badges app, or better, recommend new features and help us refine it? Join Badges App community!

想要关注我们的徽章应用，或者更好地推荐新功能并帮助我们完善它？加入徽章应用社区！