タグ付けされた質問 「requirements」

「タイプ」属性を持つエンティティがあるとします。可能なタイプは20以上あります。 ここで、タイプをA-> Bから変更できるものを実装するように求められます。これは唯一のユースケースです。 したがって、有効なタイプである限り、タイプの任意の変更を許可するものを実装する必要がありますか？または、要件ごとにA-> Bからの変更のみを許可し、B-> AまたはA-> Cなどの他のタイプの変更を拒否する必要がありますか？ 両方の長所と短所を見ることができます。一般的な解決策は、将来同様の要件が発生した場合の作業が少なくなることを意味しますが、間違っている可能性が高くなります（ただし、これで発信者を100％制御しますがポイント）。 特定のソリューションではエラーが発生しにくくなりますが、同様の要件が発生した場合、今後さらに作業が必要になります。 優れた開発者は、将来の拡張が容易になるように、変更を予測してシステムを設計する必要があると聞き続けていますが、これは一般的な解決策のように思えますか？ 編集： それほど具体的ではない例に詳細を追加する：この場合の「汎用」ソリューションは、「特定」ソリューションよりも作業が少なくて済みます。特定のソリューションでは、古いタイプと新しいタイプの検証が必要です。新しいタイプのみを検証する必要があります。

124 programming-practices  api-design  requirements 

私は、私たちのグループが始めているプロジェクトの要件と仕様の開発を任されました。 違いがわからないことに気付きました。Googleの検索でさらに混乱しました。仕様は要件であると言っている人もいるようですが、レベルは低くなっています。

122 requirements  specifications 

私が直面している問題は次のとおりです。 プロジェクトマネージャーからの引用： こんにちはSparkさん、多くの異なるiOSアプリケーションに使用できるフレームワークを開発するタスクを割り当てています。要件は次のとおりです。 UIの操作に使用されている親指または指の太さを検出できる必要があります。 この情報を使用して、UIのすべての要素を自動的に配置およびサイズ調整する必要があります。 親指を大きくするには、要素を画面の中央近くに配置する必要があります。 親指を小さくするには、要素を画面の角に近づけて配置する必要があります。 親指を大きくするには、すべてのフォントを小さくする必要があります。（この場合、大人を想定しています。） 親指を小さくするには、すべてのフォントを大きくする必要があります。（この場合、若い人を想定しています。） 概要： このフレームワークは、ユーザーフレンドリーなユーザーインターフェイスをプログラムで作成するために必要です。フレームワークは、必要な数のプロジェクトで使用できるように開発される必要があるため、開発者にとっても使いやすいものでなければなりません。 私はこのタスクを与えられた開発者なので、私の質問は次のとおりです。 これらの要件が少しばかげていることをどのように説明できますか？ 実際のプロジェクトの開発に専念する方が良いと説明するにはどうすればよいですか？ これが可能であったとしても、そのようなものを開発することはお勧めしません。 このプロジェクトに礼儀正しく、優しく、敬意を持ってノーと言うにはどうすればいいですか？ 3年の経験を持つ開発者であっても、これは不可能かもしれないことをどのように説明できますか？

74 project-management  iphone  frameworks  ios  requirements 

顧客満足の狩野モデルは、製品機能のさまざまなクラスを定義します。それらの中には 必須の品質：これらが実装されていない場合、顧客は製品を受け入れません。 魅力的な品質（喜び）：顧客が最初に期待することさえないが、発見されたときに興奮と喜びをもたらす機能。 魅力的な資質は明らかに多くのビジネス価値を持っています。5.000未満の使用済みフィアットがすべての必須要件を満たす場合、人々は500.000でフェラーリを購入します。 ただし、私が知っているすべてのアジャイルプロセスは、必須の要件を強く支持しています。これらは常に最高の優先度を取得します。アジャイルには魅力的な資質がある場所すらありません。 アジャイルプロセスはソフトウェア開発に非常に役立つと思います。しかし、どうすればそれらを適用して、必須の要件をかろうじて満たす最低限のものだけでなく、楽しい高品質のソフトウェア製品を作成できますか？ 補遺：最初の2つの答えが指摘したように、必須要件に最高の優先順位を与えることは理にかなっています。しかし、私たち（および顧客）は、必要な要件が何であるかを事前に常に知っていますか 私は、最初に高い優先度が与えられた要件が、後で役に立たないとしても、それほど重要ではないことが判明したことを何度か経験しました。したがって、私は、必要な要件に慎重に焦点を合わせるべきではないと考えています。

61 agile  project-management  scrum  requirements 

機能要件または非機能要件について疑問に思っています。これらの用語にはさまざまな定義がありますが、要件の一部を適切なカテゴリに割り当てることはできません。 たとえば、次のように、何らかのアクションに関連していない、または追加の条件がある要件について疑問に思っています。 選択したデバイスのリストで、デバイスを繰り返すことができます。 データベースには少なくとも100個のアイテムが含まれている必要があります 価値のある通貨は米ドルである必要があります。 デバイスには、ワット単位の名前と電力消費値が必要です。 それらの要件は機能的または非機能的ですか？

34 requirements 

ユーザーストーリーは、ユーザーがシステムで何をしたいのかを高レベルでキャプチャします。ユーザーストーリーがさらに多くの低レベル要件を推進することを理解しています。ユーザーストーリーはシステムの高レベル要件と同じですか？

33 requirements  user-story  requirements-management 

技術系ではないビジネスマンから要件を引き出すのに最適な方法は何ですか？ プロジェクトの仕様をまとめようとしているチームと協力しています。私たちが会い、次の会議への期待に至るたびに、私たちはビジネスの人々に彼らの要求を取り戻すように頼みます。通常、彼らは次のような反応を示します。「さて、来週私たちが好きなものを見ることができるようにプロトタイプを作り上げることができると思いますか？ 6か月以上のプロジェクトであるため、明らかに実行不可能です（全体を開発する必要があります！）。また、なんらかの仕様なしにプロトタイプを作成する方法さえ知りません。率直に言って、私はほとんどの人と同じように、彼らは自分が望むものについてある程度の考えを持っていると思います。単純に伝える代わりに、「あなたが欲しいものを与えてください、または私たちは仕事をすることができない/できない」（結果に満足してもらいたい）、彼らが望むものを決めるのを助ける方法はありますか？たとえば、次のように伝えることができます。 「表示したいすべてのデータとマージンの機能の説明とともに、希望するUIを表示する画面（Powerpoint、ナプキンなど）を描画します。これから、私たちはそれを洗練し、この一連の動作要件に基づいてバックエンドを構築します。」 または 「今どのように見えるか心配する必要はありません（1番が電話を切ります）。プログラムが追跡する各項目について必要なすべてのデータのリストを提供してください。「顧客」の場合、名前、住所、電話番号、注文などをリストすることができます。完璧なデータベース構造である必要はありませんが、これから何かを見つけて、あなたが探しているもののアイデアを得ることができます。 これらの代替アプローチのいずれかは、ビジネスの人々に彼らが望むものに焦点を当てさせるのに意味がありますか？実際に見た代替手段はありますか？

27 design  business  requirements 

私は2つの物語を持っています（私は彼らが利益部分を欠いていることを知っています） 与信管理ユーザーとして、Officeの現在と以前の給与の差異を表示できます。 与信管理ユーザーとして、Officeの現在と以前の給与の差異のPDFを含む電子メールを受信できます。 2つは、同じクエリ/フィルター基準を持つという点で関連しています。唯一の違いは、「表示」ストーリーでは結果がユーザーに表示され、「メール」ストーリーでは結果がPDFに書き込まれ、ユーザーにメールで送信されることです。 これらの2つのストーリーの共通の側面の分離に苦労しています。 たとえば、どちらも同じクエリを使用しますが、結果に対する処理は異なります。 クエリを純粋に技術的な別のストーリーに分離する必要がありますか？ PDFの作成と電子メールの送信はオフラインで行う必要がありますが、それは技術的な話になりますか？ これらの2つのストーリーを2つの機能的なストーリーと2つの技術的なストーリーに分けることができました。 システムとして、Officeの現在の給与と以前の給与の差を計算できます。 与信管理ユーザーとして、Officeの現在の給与と以前の給与の違いを確認できます。 システムとして、Officeの現在の給与と以前の給与の違いのPDFドキュメントを作成できます。 与信管理ユーザーとして、Officeの現在の給与と以前の給与の違いのPDFを含む電子メールの受信をリクエストできます。 私が戻ってくる問題は、4つのストーリーが独立しておらず、「ケーキをスライス」しないことです。 したがって、これら2つをどのように扱うかはよくわかりません。

27 agile  requirements  user-story 

私のアプリケーションには、データのフィルタリングに使用できる定義済みの式テンプレートがいくつかあります。それらの1つは " between x and y"です。QAエンジニアは、「between 100 and 200」とは異なる結果が得られるため、その定義に欠陥があると主張していbetween 200 and 100ます。式は内部的に " value >= x and value <= y"に変換されるため、2番目の境界が最初の境界より低い場合、結果は明らかにありません。同じ動作がSQLにもあることを確認しました-" between x and y"はy> = xであるか、結果がないと仮定しています。これは、少なくともSQLでは演算子が可換ではないことを意味します。 それでは、QAは、「between x and y」が可換であるべきだと思いますか？

26 requirements 

私は、終わりに近づいているWebアプリケーションに取り組んでいる唯一の開発者です。現在、2、3か月後にライブにすることを検討しています。 これは非IT企業向けのWebアプリケーションです。彼らは独自の社内ITチームを持っていますが、ライブサーバーのハードウェア要件はどうなるかを尋ねられました。RAM、32ビットまたは64ビット。 社内のITチームがこれを行うべきではありませんか、それともプロジェクトに取り組んでいるのは私だけなので、プロジェクトのパフォーマンスに影響を与える可能性のある特定のハードウェア要件を彼らに知らせるのは私の責任ですか？ 私がこの質問をしているのは、これをやったことがないからです。私はいつもサーバーを与えられ、その上にアプリを展開するように頼まれました。サーバーの構成などを心配することはありませんでした。

26 web-applications  requirements  hardware  technical-support 

技術に詳しくない人が小規模プロジェクトの仕様を書く方法を学ぶにはどうすればよいですか？ 私の友人は、統計プロジェクトの開発を外部委託しようとしています。 特に、彼はExcelで多くの作業を行っており、スクリプトの作成を外部委託して、手作業で行うことを望んでいます。 しかし、私の友人は非常に技術的ではありません。彼は技術仕様を書くのが苦手です。 彼が仕様を書くとき、それはあなたがExcelで何かをすることを記述する方法で書かれています（このセルに行き、そのセルに値をコピーします）。また、非常に冗長であり、例を何度か実行します。彼がコーナーケースを適切に説明しているかどうかはわかりません。 彼が最初に外注したプロジェクトは失敗でした。彼はいくつかの詳細を過剰に説明したが、コーナーケースを過小説明したと思う。それおよび/または彼が雇ったコーダーは、コーナーケースを熟考し、適切な質問をしませんでした。よく分かりません。私は彼とIMをしましたが、説明に5分もかからなかったはずの説明を掘り下げるのに30分かかりました。私は最後に彼のためにスクリプトを書きましたが、コーダーとの彼のプロセスが失敗した理由を調べませんでした。 彼は私に助けを求めました。しかし、彼の仕様を取り、それを明確な要件に翻訳することは、明確に書かれた仕様を実行するよりも10倍多くの作業があるため、私は関与しません。 彼が学ぶ正しい方法は何ですか？彼が使用できるリソースはありますか？コーダーとの小規模で低圧の練習プロジェクトから学ぶ方法はありますか？ 彼のスクリプトのほとんどは、統計およびデータ処理指向です。たとえば、この列を取得し、平均を実行します。これらの条件下でこれらの行を削除します。そのため、課題はWebアプリの仕様とは異なります。

24 requirements  specifications  outsourcing 

前回のアジャイルの議論ここでは何であるかを指定良い答えを持っていた重要なソフトウェア開発におけるアジャイルの方法論を実装の成功に。ポイントのほとんどは典型的な組織および管理の課題でしたが、1つのポイントは私を心配し、クライアントはプロセス全体に関与しなければならないということです。 クライアントは現実的に制御できないものの1つです。おそらく、ビジネスモデルは政府の請負業務に向いています。たとえば、厳しく厳しい契約が会社に次の義務を負わせている場合などです。 要求どおりにX機能を提供する 機能のリクエストは壁を越えて投げられますが、私たちはそれを聞きたくありません。 顧客の頭の中には機能の優先順位という概念はありません。それらはすべて重要であるか、私たちがそれらを要求しなかったでしょう。 このプロジェクトは、オーバーランや締め切りに関係なく、Y以上の費用がかかりません。 すべての作業を完全に実施するための、絶対的、厳格、最終的、交渉不能の期限。 私たちは以前にそのようなクライアントと仕事をしたことはありませんでしたが、プロジェクトのお金は過ぎ去るにはあまりにも良いです。この作業が必要です。 私はここに来て、HARDでプロセスを変更してアジャイル開発に移行しました。ここで、このプロジェクトが新しいプロセスに適合する場所を調整する方法がわかりません。私はこれまでに開発チームとプロセスをこの道に導くと信じていたオープンマインドなハンドオフ管理の贅沢を持っていませんでしたが、私たちはここにいるので、このプロジェクトが本当にアジャイルな方法。経営陣はこの道をリードしてくれると私を信じており、私たちが今いるこの状況はウォーターフォールを明確に要求しているので、彼らを失望させたと感じています。今バックトラックすると、彼らの信頼を失うかもしれないと思う。 ここにあるような他の答えは、この種のクライアントではアジャイルが不可能だと言っていますが、同意しますか？似たような状況にあり、それを機能させた人はいますか？アジャイルを成功させるためにどのような戦略を実装しましたか？

24 agile  requirements  government 

現在、私のスーパーバイザーは、バグ追跡ソフトウェアを使用して要件のドキュメント/仕様を作成しています。これは私にとってひどいアイデアのように思えます。すべての要件はこれらの小さなチケットにあり、要件を取得するためにこの馬鹿げたWebフォームをクリックする必要があります。要件/ソフトウェア仕様に対する健全なソフトウェアソリューションとは何ですか？ 明確にするために、私は非常に多くの機能を備えたこの大きなソフトウェアコンポーネントを構築しており、これらの機能はこのバグ追跡ソフトウェアで説明されています。

23 design  requirements  issue-tracking 

私は中規模の会社で働いていますが、IT部門は非常に小さいです。 昨年（2011）、私はエンドユーザーの大規模なグループに非常に人気のあるアプリケーションを書きました。昨年末に締め切りを迎えましたが、最後に欲しかったアプリケーションに一部の機能（これからfuncAを呼び出します）が追加されませんでした。したがって、このアプリケーションは2011年末からライブ/プロダクションで実行されていますが、問題なく追加できます。 昨日、エンドユーザーのグループ全体が、アプリケーションに含まれていなかったfuncAが機能しなくなったと不平を言い始めました。この会社での優先事項は、アプリケーションが破損した場合、優先プロジェクトの前に最初に修正する必要があることです。 私はコードとクエリを比較しましたが、2011年以来、違いはありません。その後、エンドユーザーの1人にプルーフBが機能しなかったことを認めさせることができましたが、それ以来、そのエンドユーザーは戻って以前に機能していると言いました...エンドユーザーの大群が同化したと思います彼女。また、このプロジェクトに関する注意事項を確認しました。このプロジェクトには、「funcAは時間の制約のために達成されていません」、proofCと明記されているプロジェクトに関する要件と毎日の更新があります。 私は彼らの多くと話をしましたが、彼らはプログラミングの背景から非常に遠いのでどこで混乱するかを見ることができますが、彼らが得るためにプロジェクトの優先順位付けをバイパスするためにグループで行動するのに十分な知性があることも知っています彼らが仕事を簡単にしたい機能。 最悪の部分は、コードやクエリの変更がなくても、グループ思考が設定され、上司とIT責任者が実際にそれらを信じ始めていることです。ロジックの状態を確認する限り、1 = 1の場合、非常にカットされて乾燥しているため、funcAは機能しません。 したがって、これで私のシナリオの説明は終わりましたが、これが原因で、おそらく引き継がれる実在しない問題を修正することに本質的に移行することになるため、パフォーマンスメトリックスに何度も触れないようにしています。 1ヶ月。

22 project-management  requirements  maintenance 

この質問はして移行され、それがソフトウェア工学スタック所に答えることができるので、スタックオーバーフローから。 6年前に移行され ました。 先ほどメールを送信しましたが、派生要件で「Shall」という言葉を使用しても機能要件に続かないことを開発者に思い出させました。機能要件を記述するとき、「必須」という言葉を使用して、派生要件が行う必要のある機能を説明します。 派生=システムは要件である機能=システムは要求を行わなければならない それは私たちの先輩の一人によって送り返されましたが、それは間違っていて、すべての要件で使用されるべきです。 私はここで間違っていますか、すべての要件で使用する必要があります。それをバックアップするものを見つけることができませんでした。

22 requirements