要件のリストを制約に変換するにはどうすればよいですか？

Question

最初のソフトウェア設計ドキュメントを作成しようとしています。私は独学で、CSの正式なトレーニングを受けていません。事前に少し読んだ後、システムの要件、品質、および非品質のリストを作成しました。これは、プロジェクトが提供するタスクの管理上の観点からの概要を提供します。これらを設計制約に変換できるようにすることが目的でした。これにより、正当な設計上の決定が導かれます。これまでのところ、提供されるリソースの詳細については詳しく説明していませんが、システムに存在するすべてのリソースに適用する必要があるという点で一般的です。

しかし、次のステップに進むのに苦労しています。設計制約はどのように見えるはずですか？それはどの程度具体的または一般的である必要がありますか？ドメイン要件を制約に変換するにはどうすればよいですか？私はすでにナッツと過剰指定されたものを行ったことがありますか？ :-)

背景
私は小さなサービス会社で唯一のプログラマーです。現在のHTMLにはPHP PIアプリケーションがあり、有機的に成長し、テストインフラストラクチャがありません。1ビットを編集すると、アプリの遠く離れた部分に影響があり、意図しない結果が生じます。これを次のように置き換えたいと思います。より専門的に設計された（実際には、あらゆる種類の設計された）もので、テストスイートを使用したオブジェクトベースです。管理者はプログラミングについて知らないので、現在の機能のどれが無意味で、どのワークフローが行き詰まっているのかなどを知る必要があります。これは、永久に延期された設計会議中と実装中の両方での私のガイダンスとなることを目的としています。

これまでのところ、私は次のとおりです。

用語

「所有者」とは、他の展開から独立したデータを使用して、ソフトウェアの独自の展開を実行している会社または部門を指します。
「開発者」とは、ソースコードへの書き込みアクセス権を持つプログラマー、または所有者のために働くデータベース管理者のいずれかである個人を意味します。
「ユーザー」とは、デプロイメントへのアクセスを認証した個人を意味します。
「スタッフ」とは、所有者のために働くユーザーを意味します。
「クライアント」とは、所有者の顧客であるユーザーを指します。

[〜＃〜]要件[〜＃〜]
サービスが示す機能が必要は何ですか？

プラットフォーム：サービスへのアクセスは、さまざまな最近から最新の一般的なビジネスコンピューティングデバイスを介して利用できる必要があります。（つまり、2013年現在のデスクトップ、ラップトップ、タブレット、スマートフォン）。
モビリティ：物理的な場所に関係なく、すべてのユーザーにサービスへのアクセスを提供するための合理的な努力が必要です。
Secure：すべてのデータにはアクセスするために認証と承認が必要であり、非安全なリクエストにはユーザーの意図によって開始されたという十分な確認が必要です。
アクセス制御：リソースおよびリソースのセットには、可変の許可権限が必要です。
管理者権限：個々のリソースおよびリソースのセットに対する読み取りおよび書き込み認証は分離する必要があります。
nbreakable：ユーザーがシステムを「壊れた」状態にすることはできません。
No Clobber：ユーザーが他のユーザーの変更を無意識に上書きすることを許可してはなりません。
オフライン：当日のユーザーのスケジュールされたイベントは、オフラインで読み取り可能である必要があります。
Rapid Bootstrap：新しいスタッフは、システムの内部で迅速にスピードアップできる必要があります。
Owner Agnostic：ある所有者に固有のものは、別の所有者の新しいクリーンなデプロイメントに存在するべきではありません。
ブランド可能：所有者は、ブランドと企業の詳細を表示するようにシステムを構成できる必要があります。
安全なデータ：すべてのデータの頻繁で信頼できるバックアップを簡単にスケジュールする必要があります。

[〜＃〜]品質[〜＃〜]
最終製品を展示する他の機能はどのようなものですか？

バグ修正のための開発者の迅速なターンアラウンド。
新機能のラピッドプロトタイピング。
新機能のエラーのない実装。
リグレッションのない変更。
魅力的なクライアントUI。
効率的なスタッフUI。
最も幅広いデバイスとOSのサポートは合理的に達成可能です。
すべての説明責任/非難データ（誰が、いつ、何をしたか）は不安定でなければなりません。
他のすべてのデータは、開発者を必要とせずに、十分な権限を持つユーザーが編集できる必要があります。
データのバックアップは、十分に承認されたユーザーがオンデマンドで作成できる必要があります。
データのバックアップは、十分に承認されたユーザーが必要に応じて復元できる必要があります。

非品質
どの機能が重要で重要ではなく、設計の柔軟性を可能にしますか？

プログラミング言語の選択
UIモノリンガリズム
一般的なリソースのインポートまたはエクスポートシステムは必要ありません。
[このリストは不完全です]

Derek · Accepted Answer

Robertがコメントで述べたように、すべての設計制約を1か所で完全に網羅できるとは私は思いません。設計上の決定を支援するために設計上の制約を文書化するつもりであるとおっしゃっていたので、ウォーターフォールスタイルの開発環境で作業していると想定しています。ウォーターフォールの開発については、Wikipediaの批評のセクションを参照してください。ウォーターフォールの開発が正当化される場合もありますが、アジャイル開発が普及している理由があります。少しずつ製品の開発を自由に開始できるので、何かが機能しないことがわかったらすぐに、その部分を捨てて、別のアプローチを試してください。また、プロジェクトの過程で要件が変化することに対して、はるかに反応します。

ウォーターフォールの開発は、多くの場合、事前に多くの管理時間を浪費します-要件が変更されたため、プロジェクトの終わりに向かって本質的に役に立たなくなるためだけに、何十ページもの長さの要件ドキュメントを処理しなければならなかった人はどれくらいいますか？その開発の過程で？

これまでのところ、設計の制約を文書化する方法に関する質問には直接答えていません。むしろ、私はあなたがすべてを前もってやらないことを提案しています。開発環境がどのようなものか（つまり、大企業の場合は自営業者であるなど）は説明しませんが、開発前に何を提供する必要があるかについての期待を変えることができるかどうか完了したら、それは非常に役立つと思います。「何をすべきか事前に文書化しますか？」という質問にひねりを加えることができる場合は、代わりに ser stories の公式化を検討することをお勧めします。事前に知っておくべきニーズ。

（ちなみに、areソロまたは小さなチームで作業している場合は、アジャイルムーブメントから生まれたリーン開発を読んでおくとよいでしょう。開発プロセスから廃棄物を取り除くことに焦点を当てています）。

ニコラスのコメントに基づいて編集：

おそらく厳しい状況にあるようですね。私の回答の上記のリンクは、あなたがよく知らない各領域をカバーしています（批評リンクの上部にジャンプして、ウォーターフォール開発 -に慣れていない場合は、完全なスクープを参照してください滝対アジャイル開発、それはあなたが前者をしていることはほぼ確実です）。

開発プロジェクトに伴うものに対する経営陣の期待がどれほど柔軟であるかについて、あなたは感じていますか？アイデアを彼らに持ち込むことに抵抗がなければ、リーンテクニックの恩恵を本当に受けられると思いますが、確かに、リーン開発の経験者が案内してくれなければ、最初は気が遠くなるかもしれません。

たまたま Pluralsight サブスクリプションをお持ちの場合（または無料トライアルにサインアップしてもかまいません）、 "ソフトウェアスタートアップのベストプラクティス" と呼ばれるコースでリーン開発の背後にある原則であり、プロジェクトの開始からこれらすべての設計上の制約を計画しようとすべきではない理由について、経営陣にもたらす議論を提供します。（または、YouTubeで視聴できるプレゼンテーションがいくつかあります）。

Michael Durrant · Answer

方法を絞り込み、アジャイル手法を使用して1つずつ実行します。

あなたが説明する状況（基本的には混乱）とあなたが望むシステム（クリーンアップ）を考えると、一度に1つの小さな部分に取り組むことをお勧めします。

これらの「資質」も削除します

バグ修正のための開発者の迅速なターンアラウンド。
新機能のエラーのない実装。
リグレッションのない変更。
魅力的なクライアントUI。
効率的なスタッフUI。
最も幅広いデバイスとOSのサポートは合理的に達成可能です。

誰もが常にこれらを望んでいるからです。これはあなたがしないでください開発者のターンアラウンドが遅い、エラー、魅力のないクライアントUI、非効率的なUIなどを望んでいることを示しているので、あなたが持っている要件について反対を考えることは役立つかもしれません。それらのいずれかが本当に必要であり、それらを要件にすることはあまり役に立ちません（ただし、それらは価値のある原則です）。それらはまた非常に一般的で非特異的です。それらのそれぞれは、詳細の悪魔のように「しかし、それは実際には実際には何を意味するのか」という質問をします。

私はあなたがリストした要件を1つずつ取り上げます。あなたは12を持っており、それぞれ1か月を主な焦点として1年間の作業に便利です。

避けなければならない最大のことは、ボリュームに圧倒され、プランニングの詳細が多すぎるという罠です。

また、各ステップで克服すべき困難や問題に直面するため、かなりの忍耐が必要になります。このような状況では、多くの場合、勝つのはカメです。

Michael · Answer

この投稿は「アーキテクチャ」としてタグ付けされているので、アーキテクチャの観点から検討します。

収集している要件の種類に関して、正しい方向に進んでいます。私はあなたがより一般的に共有したものをアーキテクチャの推進力として分類します。つまり、アーキテクチャ設計を推進するために使用できる最小限の情報セットです。ほとんどの人は、アーキテクチャドライバを4つのバケットに分割します。

技術的制約
ビジネス上の制約
高レベルの機能要件
品質属性または品質要件

「プロジェクトの計画/優先順位付け/作業割り当ての「問題」（または非機能要件）を処理する方法」および「機能要件と非機能要件を区別する必要がある理由」の説明を参照してください。？ "についての議論と背景。

制約は動かせないので、アーキテクチャの設計に大きな影響を与える少なくとも1人の利害関係者が決定を下す必要があります。制約への対処に関する具体的なアドバイスを次に示します。

制約の選択には常に十分注意してください。
システムを人為的に制約することは可能な限り避けてください。制約を作成する正当な理由があります。
設計上の決定は変わる可能性があります。制約はできません。
他の影響要因（時間、予算、脆弱性など）により、設計上の決定が制約のようになる場合があります。
要件は常に交渉可能であるため、制約になることはありません。

微妙ですが、制約と設計決定には大きな違いがあります。設計上の決定は、設計者が選択したものであるため、変更することもできます。 制約は変更できません。これは、チームとアーキテクトにとって、あなたが制御/影響を与えるものと、あなたに影響を与えるものを明確に示しているため、重要です。

制約は、システムの耐力壁と考えるのが好きです。あなたが家を建てていた場合、耐力壁は深刻な-おそらく壊滅的な-コストなしでは絶対に動かすことができないものです。他の回答でアドバイスされている可能な限り最後の瞬間までメジャー決定を延期することは素晴らしいアドバイスです。しかし、プロジェクトの開始時に行う仮定-特に柔軟なものと動かないものは、プロジェクト全体に悩まされます。

いくつかの簡単な例-

技術的制約：「お客様は、システムはApache/Linuxで実行する必要があると言っています」
ビジネス上の制約：「稼働は11月の見本市の前でなければなりません」
制約のような設計上の決定：「MongoDbを使用してデータを格納します。」あなたは後で気が変わる可能性がありますが、これはおそらく重要な決定でした。フレームワークとツールキットは、しばしばこのカテゴリーに分類されます。
設計上の決定：「ハートビートを使用してサーバーの障害を検出します」