问题标签 [requirements]

I want to provide multi-monitor support in my application.

In the past I have had the simplistic view that multi-monitor support is simply the lack of open multi-monitor related bugs. If it seems to work on a multi-monitor setup, then it supports multi-monitors, right?

But I would like to create some clear requirements about this.

What are the basic requirements I need to adhere to, in order to satisfy most users' expectations so that they might say "yes this application supports multi-monitors"?

For example an obvious requirement is that all windows/messageboxes/tooltips etc must open on the same monitor that the application is on. And any children of those windows must open on the same monitor as their parent.

Can you think of any more? Are there any guidelines about this anywhere?

我经常听到“X% 的软件项目由于糟糕的需求而失败”。该声明中的 X 介于大约 70 到 95 之间。但是，我很少听到需求如何变差。事实上，声明本身表明确实存在要求。

什么是“坏”的要求？怎样才能避免？

足够的细节就足够了，这是通常的反应。

在我们目前正忙于的项目中（它是不完整的并且在没有任何类型的 brs/文档/用户故事的情况下移交给我们，我们得到的故事如下：

作为产品负责人，我需要开发人员测试 XXX 工作流程以使其正常工作。

和

作为产品负责人，我需要开发人员测试 YYY 工作流程以使其正常工作。

没有说明“正确”是什么意思。

当要求更多细节时，会被告知你要求的细节太多，因为这是敏捷的，所以在 sprint（2 周 sprint）的后期，需求会变得更加清晰，你不应该担心当时的细节，而是只是让故事在“娃娃毛”中占有一席之地，不再困难。做一个大人物。不要担心细节。

这就是敏捷应该是什么样的吗？

我的开发团队几乎都在使用 Scrum 方法论。我们有一个优先的产品积压工作，我们将其分解为由燃尽图跟踪的冲刺。

麻烦的是，产品经理（从利益相关者那里收集需求）会给我们一个需求大纲，比如在一个 sprint 或一组 sprint 开始前几天。

然后我们浏览它们，用可行的方法（技术上和在合理的时间内）修改它们。这会被送交管理层、其他产品经理和利益相关者进行审查，并且通常会进一步修改/调整，这往往会循环往复，直到一切尘埃落定。

同时，冲刺开始日期即将到来，我们开始抓住我们非常确定稳定的需求。一旦完成了这些，随着需求的轻微变化，我们将有无数天的时间来调整代码。

虽然我知道需求不应该被认为是固定的，但我只是觉得我们管理得不好，并试图将瀑布式需求方法融入敏捷开发中。

有没有人对此类问题有任何改进建议或经验？

编辑：这对我们来说可能是最坏的情况——有时需求非常稳定，我们实际上正确地使用了 Scrum！但是，我们在 sprint 中更频繁地看到上述情况，这就是我提出这个问题的原因。我知道上面的内容并不是真正正确的 Scrum，这就是问题所在：)

How to deal with a project manager that imposes really tight deadlines but with a day or so before the deadline brings in new features and spec changes to implement, with another tight deadline.

The worst thing about this is that most of the new stuff leads to major rewriting of the existing code, as previously implemented business rules are no longer applicable or "gain" strange corner cases that need to be treated separately.

It seems that no matter how hard we try to make the system extensible, there always are things that come up literally in the last moment and need to be implemented and supported quickly.

How could I deal with such a situation? It's being really demoralizing and one colleague has already quit the team.

我不确定这是否适合stackoverflow，但我不知道还能问哪里。我正在研究 B 方法以证明需求规范的一致性，在指定操作的前提条件时，我遇到了逻辑数学符号的问题。

简化原始问题，我有一个变量，它是FLIGHT_NO x TIME x TIME 之间笛卡尔积的子集航班，其中对于每个成员 (no,td,ta)，no 表示航班号，td 表示起飞时间和到达的时间。如何使用数学逻辑符号获得 具有最大 td 值的航班元素？

在 Code Code Complete 的第 42 页上，有一个您可能想要在需求阶段考虑的需求项目清单。
在项目中（靠近列表底部）说Are minimum machine memory and free disk space specified
这曾经是您所做的任何项目中的要求吗？甚至在开始构建东西之前您是如何定义这样的要求的？

我知道这只是一个建议，坦率地说，我认为我永远不会将其包含在我的要求中，但这让我思考（这是真正的问题）..

一个人将如何估计系统要求...

我做了一个简单的申请，然后提交审核。之后，应用程序详细信息声称最低操作系统要求为 3.1.2（我使用该 SDK）。

如果我将 Target 的 iPhone OS 部署目标更改为较低的 iPhone OS，那么它可以“解决”我的问题吗？有风险吗？我使用一些 UI（图像）视图、翻页动画、NSTimer、UIDevice 来获取电池信息，并使用 AudioToolbox 框架来获得一些系统声音，仅此而已。

如何在 2.0 模拟器上测试我的应用程序？在哪里可以找到安装？我需要安装完整的 2.0 SDK 吗？我在哪里可以找到它？我已经用谷歌搜索了它，但仍然找不到。

我在 QEMU 模拟器上使用 Ubuntu ARM 作为测试平台。模拟器有 256MB 的 RAM，但我想知道：运行 Ubuntu ARM 的最低要求是什么？（仅限 CLI）

显然，通用系统模型和组织模型是使用瀑布模型的软件开发项目的需求阶段的一部分（根据我的教授），但是我们在我的软件工程课程中没有学到这一点，我的两本软件工程书籍都没有提到他们，谷歌似乎也不知道他们是什么。我不是业务开发人员，我通常不需要做任何这些事情，所以我处于陌生的领域。我必须在明天之前完成软件项目的需求、分析和设计阶段（它是昨天分配的），我无法继续进行需求部分，因为我的教授要求这些不寻常的东西。我会问我的教授，我是否认为得到回应的可能性很小，但这不太可能。