0

要件仕様書を書いた経験がありません。

私は .Net で新しい社内 Web アプリケーションを作成しており、この新しいソフトウェアのすべての要件を記載したドキュメントを受け取りました。

現在使用されている (社内で作成された) 時間追跡システムがありますが、.Net で再設計するように依頼されました。

社内でソフトウェア開発の経験があるのは私だけです。これは内部ソフトウェアであるため、そのための非常に詳細なドキュメントを書くことは期待されていません。

データベース スキーマの ERD ダイアグラムを設計しました。また、要件を Excel シートのさまざまなセクションに分割し、配信の優先度 (L、M、H) とフェーズ (1、2、3) を設定しました。

ライン マネージャーから、このプロジェクトのタイムラインを定義するように依頼されましたが、このプロジェクトで週 3 日しか働かず、フェーズ 1 を完了するのにどれくらいの時間がかかるかわからないため、少し難しいです。私が取り組んでいるプロジェクト。

要件仕様書は、Word 文書で与えられたので (簡単な言葉で) 本当に必要ですか、それとも私が設計したもの (さまざまなセクションに分かれています) に固執する必要がありますか? 必要な場合、従うことができる例はありますか?

機能仕様書も必要ですか? 要求仕様書とは違うのですか?

プロジェクトのタイムラインは通常どのように設定しますか? データベース開発からソフトウェア開発までのさまざまなタスクを定義し、それらの横に大まかな日数を設定しました。

4

1 に答える 1

3

ソフトウェア要件仕様書 (SRS)は、主にソフトウェア ベンダーと顧客の間で必要な機能に関する合意として機能します。また、要件を見積もり可能なタスクに分解し、システム要件を十分に理解するのにも役立ちます。アプリケーションのサイズによって異なります。

作成済みのドキュメントについては、ドキュメントのスケジュール/予算セクション (優先度のある要件と概算がここに入る) と非機能要件 (ERD がここに入る) に含めることができるので、両方を使用できます。

機能要件はドキュメント内のセクションであるため、SRS ドキュメントを作成することにした場合は、それが必要になり、一部のアプリケーションではそれが非常に重要になります。

タイムラインの定義について - それが私だったら:

1- 各要件の不明な % を定義します (調査が必要ですか?、最初にプロトタイプを試す必要がありますか? ..など)。大まかな見積もり [たとえば、不明な要因が 90% の場合、顧客が優先度を変更したり、機能全体をキャンセルしたりする場合があります)

2- 各要件 (既知の部分) を小さなタスクに分割します。ただし、各タスクの見積もりが 1 日を超えないことを条件とします (例: create table user 、create orm method getuser など)。

3-テストを別のタスクとして追加し（テストシナリオ以上を実行）、それに応じてコードを修正します。

4- ドキュメントが必要な場合は、30 分かかる場合でも別のタスクとして追加する必要があります。

5- マイルストーンを定義します。可能であれば、お客様と機能レビュー セッションを行うと非常に便利です (例: マイルストーン 1: デモ機能 1、2、3)。残りのタスクより優先されるタスク ログにフィードバックを追加します。(インクリメンタル サイクルで機能を開発しようとした場合、多くの再作業を避けることができます)

SRSスケルトンへのいくつかのリンク

それが役に立てば幸い

于 2012-07-27T21:30:25.200 に答える