در این ارائه به معرفی فرآیند تعیین نیازمندی ها و الزامات در توسعه یک سیستم می پردازیم.
اگر در زمینه مدیریت محصول، مدیریت پروژه یا مهندسی سیستم ها فعالیت می کنین، این ارائه میتواند برای شما مفید باشه
22. خوبامزالیکمشخصات
مثال
The Flight_Information_System shall usually be on line.
The Flight_Information_System shall have an Availability of at
least xx% over a period of at least yy hours
کلمه خود همچنانabailabilityشود تعریف نامهواژه در باید
در را سامانه شرایطی چه تحت اینکهدانیممی دسترس
25. [Condition] [Subject] [Action] [Object] [Constraint]
When signal x is received [Condition],
the system [Subject] shall set [Action]
the signal x received bit [Object]
within 2 seconds [Constraint].
مثال
A requirement statement addresses a single thought.
Completeness and singularity need to be balanced, and modularity has to be used to ensure that related requirements are grouped.
A requirement statement is complete in and of itself.
اثربخشی سایر کارها مثل تجزیه، تخصیص، صحه گذاری و اعتباردهی به این ویژگی بستگی دارد: فهم یک الزام، مستقل از سایر الزامات
البته میتوان به سایر اسناد یا استانداردها ارجاع داد
When customer requirements specify design, it should be questioned.
A proper requirement should deal with the entity being specified as black box by describing what transformation is to be performed by the box
The requirement should specify ‘what’ is to be done at that level, not ‘how’ it is to be done at that level.
یک مفهوم واحد توسط نویسنده، طراح و تست کننده درک شود
یک مفهوم واحد توسط نویسنده، طراح و تست کننده درک شود
یک مفهوم واحد توسط نویسنده، طراح و تست کننده درک شود
مثال گفته شده یک الزام معتبر، اما غیرقابل ارزیابی (صحه گذاری) است. این نوع الزام نشانه ای است مبنی بر اینکه یک مصالحه (trade study) برای مشخص کردن الزام حداکثر برد مورد نیاز است.
هر الزامی بایستی فقط از طریق یک روش صحه گذاری شود. اگر روش های متعددی برای صحه گذاری یک الزام موردنیاز است، آن الزام بایستی به الزامات ریزتر شکسته شود.
وقتی که همه ی الزامات در یک سازمان شکل و شمایل واحدی داشته باشند و از یک تمپلیت استانداردی پیروی کنند، نوشتن، بازبینی و صحه گذاری هر الزام آسان تر خواهد بود.
Have and use just one term per concept in the whole set of requirements. Synonyms are not acceptable.
Use a glossary to define each term used.
This may be as simple as a list of nouns and verbs allowable in the project.
Conditions are measurable qualitative or quantitative attributes that are stipulated for a requirement. They further qualify a requirement that is needed, and provide attributes that permit a requirement to be formulated and stated in a manner that can be validated and verified. Conditions may limit the options open to a designer. It is important to transform the stakeholder needs into stakeholder requirements without imposing unnecessary bounds on the solution space.
Constraints restrict the design solution or implementation of the systems engineering process. Constraints may apply across all requirements, may be specified in a relationship to a specific requirement or set of requirements, or may be identified as stand-alone requirements (i.e., not bounding any specific requirement). Examples of constraints include: interfaces to already existing systems (e.g., format, protocol, or content) where the interface cannot be changed, physical size limitations (e.g., a controller shall fit within a limited space in an airplane wing), laws of a particular country, available duration or budget, pre-existing technology platform, user or operator capabilities and limitations.
Conditions are measurable qualitative or quantitative attributes that are stipulated for a requirement. They further qualify a requirement that is needed, and provide attributes that permit a requirement to be formulated and stated in a manner that can be validated and verified. Conditions may limit the options open to a designer. It is important to transform the stakeholder needs into stakeholder requirements without imposing unnecessary bounds on the solution space.
Constraints restrict the design solution or implementation of the systems engineering process. Constraints may apply across all requirements, may be specified in a relationship to a specific requirement or set of requirements, or may be identified as stand-alone requirements (i.e., not bounding any specific requirement). Examples of constraints include: interfaces to already existing systems (e.g., format, protocol, or content) where the interface cannot be changed, physical size limitations (e.g., a controller shall fit within a limited space in an airplane wing), laws of a particular country, available duration or budget, pre-existing technology platform, user or operator capabilities and limitations.