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

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

33 requirements  user-story  requirements-management 

プロジェクトの入札段階では、多くの場合、潜在的な顧客からソフトウェアシステムの要件をさまざまなソース[メール、ワードドキュメント、Excel]から非常に非構造化された形式で受け取ります。通常、彼らが抱えるビジネス上の問題に対するこれらの「提案された解決策」を考え出すのは、顧客側からの「製品開発」担当者の集まりです。彼らはビジネス分野の専門家ですが、多くの場合、彼らは正しい解決策を持っていません。 これにより 同じ要件の複数のバージョン 2つの要件を1つに混ぜる 後の要件のいくつかのバージョンでは、一緒に結合された要件が再び分離され、それぞれが新しい追加の一部を取ります 開発を開始する前に、このような要件をどのように処理し、適切なユースケースに分類しますか？特定の要件の履歴を追跡するために、最初に考案されてから適切なユースケースに結晶化するまで、どのツールを使用できますか？このような方法で受け取った要件に対する作業の見積もりは、要件を正しく理解し、それに対する作業を正しく見積もるのを間違えてしまうという悪夢です。 私たちがプロジェクトに勝った後、顧客は自分の要件をさらに考え、適切にそれを明確にすることができました。この場合に発生することは、一部の機能が削除され、一部が機能強化され、一部がまったく新しい方向に進むことです。これは基本的に、プロジェクトに勝つ前に行われた作業項目の見積もりの​​一部を無効にする可能性があります。特定の要件のツリーを構築できるシステムがあるかどうか、および各ブランチがどのように異なる推定値をもたらすかを知りたいと思います。 このアクティビティをより管理しやすくするためのヒント、ツール、トリックはありますか？要件管理や労力の見積もりよりも経験豊富な人から洞察を得ようとしています。

21 requirements  development-methodologies  use-case  requirements-management  engineering 

アジャイルプロジェクトの短期的な要件管理は、私にとっては解決された問題のようです。 スクラムアングルから、新しい要件または既存の要件への変更がユーザーストーリーを通じて提供されます。また、EpicまたはFeatureの下にグループ化されたユーザーストーリーにより、より複雑な要件の配信が容易になります。 もちろん、ユーザーストーリーは技術的には要件文書ではありません。これは、機能の垂直スライスと呼ばれることが多いものにマッピングされる、管理可能な作業グループです。また、これらのストーリーの範囲は、承認基準（AC）を使用して明確に定義できます。 そのため、ユーザーストーリーは正式な要件ではありませんが、ユーザーストーリーを参照することで、ユーザーの基本的な要件をかなり明確に把握できます。短期的に。 プロジェクトが進行するにつれて、ユーザーストーリーの数が増加するため、短期間で言います。したがって、増え続けるストーリーのリストを閲覧して要件を見つけることは、時間の経過とともに効率が低下します。 この問題は、以前のストーリーを拡張したり、置き換えたり、さらには無効にするユーザーストーリーを検討するとさらに悪化します。 ここで、プロジェクトでの開発の反復間の2年のギャップを想像してください（本番環境で安定）。元のチームはなくなり、すべての知識も失われました。 元のチームがこれが起こるとわかっていた場合（たとえば、ビジネスの性質）、その後のチームを支援するためにどのような対策を講じることができましたか？ 確かに、バックログはいくつかの情報を提供しますが、簡単に閲覧できる形式ではほとんどありません。 それでは、後続のチームがプロジェクトの状態を理解するために何ができるか、なぜそれがどのようにそこに到達したのかを含めて？ 私の経験では、次のことはうまくいきません。 バックログを要件ドキュメントとして読み取ることができるように、以前のユーザーストーリーを削除または更新するバックロググルーミング。 ドキュメントスプリント。チームメンバーがシステムの現在の状態をド​​キュメント化するタスクを担当します。 動作テストによる文書化。このアプローチは、私が仕事に近づいているのを見た唯一のものです。残念ながら、コード化された動作テストはネーミング問題の犠牲になります。テストはシステムを適切に文書化するかもしれませんが、変動する開発者チームが同じドメイン用語、表現、スタイルに従ってテストを作成することはほとんど不可能です。 繰り返しますが、 長期的にアジャイルプロジェクトの要件をどのように管理しますか？

14 agile  requirements  requirements-management 

Javaに基づいてタスクを実行しましたが、先輩が私にグローバル化されたバグ追跡ツールを作成するための要件を収集するように割り当てました。 ウィキペディア とmindtoolsのWebサイトから多くのタイプの要件を読みましたが、非常に混乱していました。 機能要件、運用要件、技術要件の正確な違いは何ですか？

13 project-management  terminology  requirements  requirements-management 

私は要件の仕様を作成していますが、要件の一部をフレージングすることにはジレンマがあります。 シナリオ：Webサイトからファイルをダウンロードし、ダウンロードしたファイルをCMツールのアイテムに添付する必要があります。ダウンロードしたファイルには、ASCII、ISO-8859-1、日本語などの名前が含まれています。 以下の表現では、「非ASCII」はすべての状況をカバーしていますか？ ダウンロードしたファイル名には非ASCII文字が含まれている可能性があり、これを処理してもアプリケーションがクラッシュすることはありません

12 requirements  requirements-management 

開発期間中に仕様を変更してはいけない理由を企画部新入社員に説明したい。

11 requirements  specifications  requirements-management 

当社では、複数のチームが同時に複数のプロジェクトのさまざまなコンポーネントに取り組みます。たとえば、あるチームが特定の種類のプロジェクトに特定の種類のソフトウェア（またはハードウェア）を作成し、別のチームが別の特定の種類のソフトウェアを作成する場合があります。Jiraプロジェクトを使用して特定のプロジェクトの問題をホストし、Jiraボードを使用して異なるチームのスプリントを実行します。 私たちはプロジェクト間でコードの重複を回避するという問題に直面し、それらのプロジェクトで使用する一連のコアライブラリを開発しました。プロジェクトに取り組んでいる間に、一部の開発者は、自分が書いたコードの一部がより興味深く、コアライブラリに抽出する必要があること、または使用している一部のコアコードにバグがあり、さらにパラメーター化が必要であること、または新機能...あなたはそれに名前を付けます。 したがって、コアプロジェクトのバックログに入るコアライブラリの問題を作成します。これらの問題はすべて、コアライブラリミーティング（週に1回）でレビュー、優先順位付け、推定され、将来のスプリントでは（プロジェクト固有の問題と共に）優先順位に従って取り組みます。 優先順位付けは問題を並べ替えることで行われ、並べ替えられた問題にsortedラベルを付けます（並べ替えられていない問題を検索できるようにするため）。次に、コアコンポーネントごとに1つの課題をバックログの先頭に手動で配置して、それらを最初に処理します。一部のチームがそのような問題をスプリントに入れる場合、代わりに別のアイテムをバックログの上部に手動でドラッグする必要があります。 これはかなりエラーが発生しやすいです。基本的に、私たちが持っているのは、「未解決」と「進行中」の間の「ソート済み」と「推定済み」の追加の問題ステータスです。これをsortedラベルとボード内での位置で反映することは、かなり面倒でエラーが発生しやすくなります。（たとえば、誰かがスプリントで問題を上下に移動すると、これはコアボードに反映され、数週間前の広範なディスカッションでチームが決定した可能性がある問題の順序を静かにスクランブルします。） これを実装するより良い方法は何でしょうか？

9 agile  project-management  user-story  requirements-management  jira 

ユーザーストーリーを採用して、重いSRS（ソフトウェア要件の仕様）ではなく、軽量な方法で利害関係者の「意図」を捉えることを計画しています。ただし、彼らはストーリーの価値を理解していますが、すべての属性、優先度、入力、出力、ソース、宛先などを備えたSRSのような言語にストーリーを「変換」したいという要望がまだあるようです。 ユーザーストーリーは、アーティファクトのような正式なSRSの必要性を "排除"するため、SRSを持つことのポイントは何ですか？システムの機能要件を取得するためにユーザーストーリーを採用した場合、SRSは「排除」されることを私のチーム（ちなみに、教育と実践の両方で非常に有能なCSスタッフ）にどのように説得する必要がありますか？（NFRなどもキャプチャできますが、それは質問の意図ではありません）。 だからここに私の「ワークフロー」の引数があります：ユーザーストーリーとして初期要件をキャプチャし、後でユースケースにそれらを詳しく説明します（これは低レベルでドキュメント化する必要がある、つまりUIプロトタイプ/モックアップとの相互作用を説明し、成果物です）展開）。したがって、ユーザーストーリーからユースケースへと移行するのではなく、ユーザーストーリーからSRSへと移行します。 現在、職場でユーザーストーリーをキャプチャしている場合（ある場合）、ユーザーストーリーが存在する場合にSRSが存在しないことを「主張する」ことをどのように提案しますか？

9 agile  requirements  user-story  requirements-management 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 私は18か月間、プログラマーとして（多くの顧客に再配布される）ガソリンスタンドの汎用ソフトウェア用に設計されたプロジェクトに取り組んできました。プロジェクトは大きいです。現在、約150のテーブルがあります。特定のアプローチは使用していません。適切に管理されていません。 personテーブルには今日約70列ありますが、15か月前には約30列でした。これらの新しいフィールドは、販売、財務、会計などの他のモジュールと統合するために登場しました。また、多くのフィールドが作成されてから削除されました。 その結果、多くのリファクタリングとリワークがありました。常に新しい要件が発生しているため、プロジェクトの準備はできません。 ここに私の疑問があります。通常の仕様アプローチを使用した場合、インタビュー、要件文書、アクティビティ、シーケンス、およびクラス図があり、「人」テーブルには70個のフィールドが必要であることを最初から知っているので、多くのリファクタリングを避けていました。 スクラムはこのプロジェクトに役立ちますか？この場合、スクラムも多くのリファクタリングを行うことになると思います。 私はプログラマーであり、プロジェクトマネージャーではありません。私はそれがどのように行われるべきであったのか疑問に思っています：スクラムまたは大きなデザインを前もって。 編集する この話の終わりを補足するだけです。8か月後、私はこの質問をしました。プロジェクトをいくつかの「テスト衣装」で生産した後、プロジェクトは公式に失敗しました。製品の所有者はプロジェクトを中止することを決定しました。問題の修正が難しくなり、多くのパフォーマンスの問題が発生しました。

8 scrum  requirements-management 

新しいソフトウェア製品の研究開発をしています。 経営陣は当然のことながら、明らかに顧客に利点をもたらす主要機能に焦点を当てています。しかし、同様に重要と見なすことができる多くの要件があります（例：パフォーマンス、将来の拡張性、データのトレーサビリティ、セキュリティ、スムーズなUI）。これらの暗黙の要件は、おそらくすべての製品の数が多く、満たされていない場合、顧客を不幸にする可能性があります。 どういうわけか、開発中にこれらのものが自動的に実装されるようになることが予想されます。私にとっては、すべてがそれ自体の注意と開発努力を必要とする原子的な側面です。 経営が忙しくて、そういうところに目が行き過ぎているのではないかと感じています。開発者の誇り、品質管理、および費やした労力を説明できるようにするために、暗黙の要件をいつどのように文書化して伝達する必要がありますか？ （つまり、製品に存在するが、顧客または管理者のいずれとも明示的に話し合われていない機能） 明確化 質問に関心をお寄せいただきありがとうございます。これまでの回答の主な要点は次のようです。 「暗黙の要件を明示的にする必要があります。」 ネズミ...それは私には起こりませんでした。 私が意味する要件には、次のタイプがあります。 お客様がこれらの要件について聞くことはできません。私は、製品がどのように満足するかについて話すのではなく、製品が失敗する可能性がある方法の長いリストを提示するからです。 忙しい経営者は、「明白な」機能について話すとき、私は彼らの時間を浪費していると感じています。 実装中は、これらの要件の一部のみを説明できます。計画中、特定の問題は開発中に集中的な努力を必要とするかもしれないと直感するだけかもしれません。 会社のトーテムポールで必要な高さではなく、自分の労働条件を決定している。 本格的な要件よりも労力をかけずに、[暗黙の]要件をセミフォーマル化する方法のガイドラインを求めていますが、判断の準備をしているので、手ぶらで捕まることがありません。

8 project-management  requirements-management 

SRSのソフトウェア要件にラベルを付けるための適切な戦略は何ですか？ 通常、ヘッダーにはアウトライン番号が使用されますが、ドキュメントに新しい見出しが挿入されると、番号が付け直されます。私にとっては、各ソフトウェア要件に対してより安定した指定を目指すことは良い考えのようです。これにより、更新されたSRSがあっても、特定の要件を参照しやすくなります。 これに関するあなたの経験は何ですか？

8 requirements  requirements-management