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

要件の変更によって「アジャイル」と定義されたプロジェクトのこの問題が発生したことはありますか？私は4週間のSprintで実行される開発プロジェクトに取り組んでいますが、これらのSprintの間には常に変更があります。それでもアジャイルとして定義されていますか？私はそれがサブアジャイルプロセスのようなものだと感じています-アジャイルプロセスの要件は、スプリントの始めに定義され、その終わりに向かってレビューされるべきです。私はこれで正しいですか？この経験を教えてください。

10 agile  requirements 

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

9 agile  requirements  user-story  requirements-management 

要件管理を改善する方法を検討しています。現在、Word文書をWebサイトで公開しています。残念ながら、（私の知る限り）あるリビジョンから次のリビジョンへの変更を確認することはできません。私は、wikiやVCSのように（または両方がbitbucket上のwikiのように！）できるようにしたいのですが。 また、各ドキュメントは、開発者が所定の期限までに満たすことが期待される変更について説明しています。蓄積されたアプリ機能のコレクションはどこにも文書化されていないため、レガシーアプリをすばやく修正しようとすると、バグと（設計が不十分な）機能を区別するのが難しい場合があります。 だから私はフィードバックを得たいと思っていました。何について： 誰がいつ何を変更したかを追跡できるようにwikiを使用します（ほとんどの場合、前回の表示以降に編集が行われたかどうかを確認するためにも）。 たとえば、期限ごとではなく製品ごとに1つのwikiページを用意し、実装すべき変更ではなく製品のすべての機能に対応します。このようにして、ページの特定のリビジョンを確認して、特定の時点でアプリが何をすべきかを確認できます。また、次の期限までに要件を実装するための最後のリリース以降のページの変更を確認できます 。 ワダヤシンク？

9 documentation  project-management  wiki  requirements 

私の質問は、要件抽出と要件分析の間に細い線を引くことを目的としています。これら2つの違いは何ですか？

9 requirements 

それらは同じもののように見えるので、その違いをもう少しよく理解しようとしています。 私は要件を使用していないプロジェクトで仕事をしていて、すべてが受け入れ基準であり、両方を持っているプロジェクトで働いています。

9 agile  requirements  acceptance-testing 

私はかんばんについて少し読んでいますが、要件のトピックについて少し混乱しています。 現在のプロジェクトでは、スクラムを使用しています。スプリントの最初に、BAがストーリーのウォークスルーを行い、彼女ができる限りそれを説明するセッションがあります。次に、その話を取り、レビューし、話し合い、BAに次のスプリント計画セッションのための質問を準備します。次のセッションでは、BAがすべての質問に答え、セッションは要件を理解した（ほとんどの場合）ことで終了します。 次のステップは、技術設計を作成し、ソリューション/ストーリーを開発することです。 かんばんに関​​して、私が読んだすべては、かんばんにはスプリント計画がないことを示唆しています。私の質問は、技術の要員とビジネスマンが一緒に座って（カンバンで）ストーリーの要件について話し合うときですか？プロダクトマネージャーまたはBAは、カンバンのストーリーのウォークスルーを提供しませんか？ スクラムを使用すると、BAは通常、スプリント全体で開発をサポートするために使用でき、かんばんと同じだと思います。カンバンでは、スプリントの計画がない場合、技術者はどのようにストーリーを理解するのかはわかりません。

8 agile  requirements  kanban 

ユースケース（図ではなく説明について話している）と、要件を収集してより適切に整理するために使用されるユーザーストーリーの両方について聞いたことがあります。 私は一人で仕事をしているので、要件を整理し、開発で何をすべきかを理解するための最良の方法を見つけようとしています。巨大なドキュメントなどを扱う正式な方法論はありませんし、必要もありません。 私が製品バックログを作成するために使用されているように見えるユーザーストーリーには、開発で実行する必要があるすべてのものが含まれています。 一方、ユースケースは、システムでの処理方法、外部のアクターとシステム間の相互作用のフローの説明を提供します。 1つのユースケースに複数のユーザーストーリーがあるように思えます。 これは私に次の質問を導きます：要件を見つけるとき、最初に何をすべきですか？ユーザーストーリーを見つけて書いたり、ユースケースを見つけて書いたりしますか？それとも、何とかして「同時に」行う必要がありますか？ 私は実際にはかなり混乱しています。ユースケースとユーザーストーリーに関して、単独で作業する開発者にとって、より良い開発を行うためにこれらの方法論を正しく使用するには、良いワークフローとは何ですか？

8 agile  requirements  user-story  use-case 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 3年前休業。 私は大手小売業者のIT部門で働いており、ウェブサイトの主要なシステムを再設計するためのプロジェクトを開始しました。 ビジネスユーザーは、システムを更新して改善したいと考えています。彼らはそれがどのように機能するかについて非常に高レベルの原則をいくつか持っていますが、それはそれについてです。 経営陣は、利用可能なリソースがあるため、開発チームが「何かを行う」ことを開始することを望んでいます。 開発チームとしての時間を過ごすための最良の方法を考えるのに苦労しています。ビジネスユーザーと一緒に座っても、非常に高レベルの原則や、ユーザーが望まないことは何も実現していませんが、要件への取り組みを検討することはありません。 機能の具体的な実装を漠然としたビジネス要件に関連付け、技術的な専門知識の欠如とビジネスからの賛同を得て、ビジネスが結果に満足できるようにするにはどうすればよいですか？

8 requirements  customer-relations 

最近、Haskellで実装されている小さなプロジェクトに取り組むよう割り当てられました。オブジェクト指向/命令的な背景から来て、コーディングの前に要件/ユーザーストーリーをユースケースとシーケンス図に変換することに慣れています。 しかし、私が割り当てられているHaskellプロジェクトでは、チームはユーザーの要件を述語論理命題/ステートメントに変換することを好みます。セーフティクリティカルなシステムやソフトウェアエンジニアリングの正式な方法でロジックが使用されていることは知っていましたが、日常のプログラミングではそれほどではありませんでした。これはFPレルムで一般的な方法ですか？これについてどこでもっと知ることができますか？ 要件を「モデル化」し、述語から「関数」を導き、関数が操作するために必要な型仕様を書き留めるのは自然な方法のようです。しかし、それは実際にどのように行われる/推奨されるのですか、それとも私のチームに固有のものですか？ （ここでこの質問をする前に徹底的に検索してみました。「関数型プログラミングの要件仕様」（および異なるキーワードの同義語と組み合わせ）を検索しても、意味のあるものは何もありません。）

8 functional-programming  requirements  haskell  logic  formal-methods 

受け入れ基準に関するこのブログの投稿で、著者は適切な受け入れ基準は次のようでなければならないことを説明しています。 解決策ではなく意図を述べる（たとえば、「ユーザーはドロップダウンからアカウントを選択できる」ではなく「ユーザーはアカウントを選択できる」） 実装に依存しない（理想的には、この機能/ストーリーがWeb、モバイル、音声起動システムなどに実装されるかどうかにかかわらず、フレージングは​​同じです） 比較的高いレベルである（すべての詳細が書面である必要はない） 次のような詳細： 列見出しは「バランス」です ローリングバランスの形式は99,999,999,999.9 D / CRです。 チェックボックスではなくドロップダウンを使用する必要があります チームの内部ドキュメントまたは自動受け入れテストのいずれかに移動する必要があります ただし、GUIテストを実行するためにCucumberまたは同様のフレームワークを使用することについて眉をひそめる人々をよく耳にします。さらに、内部ドキュメントを使用すると、ドキュメントを定期的に更新できないために多くの問題が発生する可能性があります。 私はまだ、お客様との会話中にそのような詳細をキャプチャする効果的な方法を見つけるのに苦労しています。

8 agile  development-process  scrum  requirements  user-story 

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

8 requirements  requirements-management 

私はスクラムとTDDに取り掛かっていますが、いくつかの混乱があると思います。フィードバックについてお聞きしたいと思います。バックログにユーザーストーリーがあり、TDDの一部として開発を開始するために、これまでの要件が必要であるとしましょう。 プロダクトマネージャーとQAがユーザーストーリーを受け入れて受け入れテストに分解する責任を負うべきだと言うのは本当ですか？ 受け入れテストは形式的である必要があるため、上記は正しいと思います。テストとして使用できるだけでなく、製品が要件であることを製品が承認できるように、人間が読める形式でも使用できます。 私が後でこれらの受け入れテストを受けて、それを私の要件として使用すること、つまり、それらが（TDDを介して）実装する一連のユースケースであることも本当ですか？私は混乱をあまり作りすぎていないといいのですが、それが今私が考えている現在の流れです。 更新 当初の意図は不明確だったので、言い換えます。TDDの使用中にユーザーストーリーをコードに変換するスクラムフローの詳細を知りたい。 開始点は明らかです。ユーザーはニーズ（または製品としてのユーザーの代表）を表面化します。これは、既知の形式で1〜2行の短い説明であり、製品のバックログに追加されます。 春の計画会議がある場合、ユーザーストーリーはバックログから取得され、開発者に割り当てられます。 開発者がコードを作成するには、要件が必要です（特に、要件はテストの派生元であるため、TDDで必要です）。 いつ、誰が、どの形式で要件がコンパイルされますか？ 私が頭に浮かんだのは、製品とQAが受け入れテストを介して要件を定義することです（私はFitNesseまたはソートを使用して自動で考えていますが、それは私が考えるコアではありません）同時に2つの目的を果たすのに役立ちます： 彼らは「完了」を適切に定義しています。 それらは、開発者にテストの派生元を提供します。 これらがいつ記述されたかはわかりませんでした（スプリントが選択される前に追加情報が届くか、ストーリーが選択されないため、繰り返しの間に開発者がスタックを待機する可能性があるため、これは無駄になります）。 ..）

8 agile  scrum  tdd  requirements  acceptance-testing 

私は現在、ソフトウェア開発者として働いており、ソフトウェア工学の学位を取得しています（前者は後者を行いません）。 私は自分の能力を十分に発揮できると確信していますが、もっと上手にできると感じています。私の最大の落とし穴は私のビジネススキルにあることを知っています。たとえば、なぜそのような方法で何かを実装するように求められるのか、最初はよくわかりません。その背後にあるビジネス要件を理解していないためです。 私のビジネススキルを向上させる上で何か良いアドバイスはありますか？それとも経験に伴うものですか？

8 requirements  business-logic 

大規模な組織で作業する場合、開発チームのメンバーがクライアントに直接アクセスして要件を収集できないことがよくあります。アカウントマネージャーに質問のリストを提供して、あなたに代わって要件を収集できるようにすることは可能ですか？

8 requirements 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 4年前休業。 私は自分が初心者プログラマだと思います-初心者はあなたが好きです。そのため、これまでにないことを行うプロジェクトでプロジェクトを開始する方法がまだわかりません。 たとえば、YouTubeから動画をダウンロードして、ユーザーが指定した形式に変換できるプログラムを書きたいと思います。私はこれまでこのようなことをしたことがなく、どこから始めればいいのか本当にわかりません。むしろ、何を検索すればよいかわかりません。 「YouTubeダウンローダー」を検索すると、既存のYouTubeダウンローダーサイトへの無用なリンクが大量に表示されますが、そのほとんどは機能しません。 私が知りたいのは、私が何も知らないプロジェクトを始める方法です。このプロジェクトに必要なものを見つけるにはどうすればよいですか？これに最適な言語を見つけるにはどうすればよいですか？特に役立つAPIがあるかどうかを確認するにはどうすればよいですか？また、新しいプロジェクトに取り組む準備をするときに、他にどのような質問をする必要がありますか？

8 programming-practices  requirements