Software Development Process The User Requirement Document Template

Mobilefish.
com document SDP-MF-URD-0001

Voyager Street 10 version 1.0
9999 XX Zaandam date 3 Jul 2006
The Netherlands page 1
Security class
Restricted
Title
Software Development Process

The User Requirement Document template
Summary
This report is a User Requirements Document template which can be used for small projects.
name department date signature
prepared
checked
agreed
approved
authorize
d
REVISION RECORD
version date pages affected brief description of change
All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of any PROJECT-COMPANY-
information contained therein for purposes other than provided for by this document, is not URD-0001.doc
permitted, except with prior and express written permission of Mobilefish.com.
Mobilefish.com document SDP-MF-URD-0001
1.0 3 Jul 2006 All First issue.
Table of Contents
1 INTRODUCTION 4
1.1 PURPOSE OF THE DOCUMENT 4
1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS 4
1.3.1 [Definitions] 4
1.3.2 [Acronyms] 4
1.3.3 [Abbreviations] 4
1.4 REFERENCES 4
1.5 OVERVIEW OF THE DOCUMENT 4
2 GENERAL DESCRIPTION 5
2.1 GENERAL CAPABILITIES 5
2.2 GENERAL CONSTRAINTS 5
2.3 USER CHARACTERISTICS 5
2.4 OPERATIONAL ENVIRONMENT 5
3 SPECIFIC REQUIREMENTS 6
3.1 CAPABILITY REQUIREMENTS 6
3.1.1 [subsection] 6
3.1.2 [ ... ] 7
3.2 CONSTRAINT REQUIREMENTS 7
1 Introduction
1.1 Purpose of the document

This document describes the user requirements for the Mobilefish.com website.
.Mobilefish.com ‫يصف هذا المستند متطلبات المستخدم لموقع‬
1.3 Definitions, acronyms and abbreviations

‫التعاريف والمختصرات واالختصارات‬
1.3.1 [Definitions]
1.3.2 [Acronyms]
UML Unified Modelling Language
URD User requirements Document
1.3.3 [Abbreviations]
1.4 References
[1] Guide to applying the ESA software engineering standaards to small software projects, ESA
BSSC(96)2 Issue 1, May 1996.
http://www.mobilefish.com/downloadswdevelopment/bssc962.pdf
From this Web page, access can be obtained to this document.
1.5 Overview of the document
2 General Description
The general requirement of this project is to change the existing static website into a CMS based website based. The
CMS used is the Drupal content management system.
‫ نظام إدارة المحتوى المستخدم هو‬.‫الشرط العام لهذا المشروع هو تغيير موقع الويب الثابت الحالي إلى موقع ويب قائم على نظام إدارة المحتوى‬
.‫نظام دروبال إلدارة المحتوى‬
2.1 General capabilities

[Describe the main capabilities required and why they are needed.]
].‫[صف القدرات األساسية المطلوبة وسبب الحاجة إليها‬
2.2 General constraints

[Describe the main constraints that apply and why they exist.]
].‫[صف القيود الرئيسية المطبقة وسبب وجودها‬
2.3 User characteristics

[Describe who will use the software and when.]
].‫[صف من سيستخدم البرنامج ومتى‬
2.4 Operational environment

[Describe what external systems do and their interfaces with the product. Include a context diagram or
system block diagram.]
].‫ قم بتضمين مخطط سياق أو مخطط كتلة النظام‬.‫[صف ما تفعله األنظمة الخارجية وواجهاتها مع المنتج‬
3 Specific Requirements
[List all specific requirements, with attributes.
User requirements fall into two categories: capabilities needed by users to solve a problem or achieve an
objective; constraints placed by users on how the problem is to be solved or the objective achieved.
Each user requirement must include the attributes listed below.
Identifier - each user requirement shall include an identifier, to facilitate tracing through subsequent phases.
Need - essential user requirements shall be marked as such. Essential user requirements are non-
negotiable; others may be less vitally important and subject to negotiation.
Priority - for incremental delivery, each user requirement shall include a measure of priority so that the
developer can decide the production schedule.
Stability - some user requirements may be known to be stable over the expected life of the software; others
may be more dependent on feedback from the SR, AD and DD phases, or may be subject to change during
the software life cycle. Such unstable requirements should be flagged.
Source - the source of each user requirement shall be stated. This may be a reference to an external
document (e.g. system requirement document) or the name of the user, or user group, that provided the user
requirement.
Clarity - a user requirement is clear if it has one, and only one, interpretation. Clarity implies lack of
ambiguity. If a term used in a particular context has multiple meanings, the term should be qualified or
replaced with a more specific term.
Verifiability - each user requirement shall be verifiable. This means that it must be possible to: check that
the requirement has been incorporated in the design; prove that the software will implement the requirement;
test that the software does implement the requirement. ]
[‫ مع السمات‬، ‫ المحددة‬g‫ضع قائمة بجميع المتطلبات‬.
‫ القدرات التي يحتاجها المستخدمون لحل مشكلة أو تحقيق هدف ؛ القيود التي يضعها المستخدمون على كيفية حل‬:‫ المستخدم إلى فئتين‬g‫تنقسم متطلبات‬
‫المشكلة أو تحقيق الهدف‬.
‫ كل مستخدم السمات المدرجة أدناه‬g‫يجب أن تتضمن متطلبات‬.
‫ يجب أن يشتمل كل مطلب مستخدم على مُعرّ ف لتسهيل التتبع خالل المراحل الالحقة‬- ‫المعرّ ف‬.
‫ المستخدم األساسية غير قابلة للتفاوض ؛ قد يكون اآلخرون أقل أهمية من‬g‫ متطلبات‬.‫ المستخدم األساسية على هذا النحو‬g‫ يجب تحديد متطلبات‬- ‫الحاجة‬
‫الناحية الحيوية ويخضعون للتفاوض‬.
‫ يجب أن يتضمن كل متطلب للمستخدم مقياسً ا لألولوية حتى يتمكن المطور من تحديد جدول اإلنتاج‬، ‫ للتسليم اإلضافي‬- ‫األولوية‬.
ً
g‫اعتمادا على التعليقات‬ ‫ المستخدم مستقرة خالل العمر المتوقع للبرنامج ؛ قد يكون اآلخرون أكثر‬g‫ قد يكون من المعروف أن بعض متطلبات‬- ‫االستقرار‬
‫ الواردة من مراحل‬SR ‫ و‬AD ‫ و‬DD ، ‫ يجب وضع عالمة على هذه المتطلبات غير المستقرة‬.‫أو قد يخضعون للتغيير أثناء دورة حياة البرنامج‬.
‫ أو مجموعة‬، ‫ قد يكون هذا إشارة إلى مستند خارجي (مثل مستند متطلبات النظام) أو اسم المستخدم‬.‫ يجب ذكر مصدر متطلبات كل مستخدم‬- ‫المصدر‬
‫ المستخدم‬g‫ التي قدمت متطلبات‬، ‫المستخدمين‬.
‫ إذا كان للمصطلح المستخدم في سياق‬.‫ الوضوح يعني عدم وجود غموض‬.‫ يكون مطلب المستخدم واضحً ا إذا كان يحتوي على تفسير واحد فقط‬- ‫الوضوح‬
ً
‫تحديدا‬ ‫ فيجب تحديد المصطلح أو استبداله بمصطلح أكثر‬، ‫معان متعددة‬
ٍ ‫معين‬.
‫ التحقق من أن المتطلب قد تم دمجه في‬:‫ وهذا يعني أنه يجب أن يكون من الممكن‬.‫ يجب أن تكون متطلبات كل مستخدم قابلة للتحقق‬- ‫إمكانية التحقق‬
‫التصميم ؛ إثبات أن البرنامج سينفذ المتطلبات ؛ اختبار أن البرنامج ال ينفذ المتطلبات‬. ]
3.1 Capability Requirements

[Capability requirements describe functions and operations needed by users. Quantitative statements that
specify performance and accuracy attributes should form part of the specification of a capability.
Space and time dimensions can be useful for organizing capability requirements. It is often convenient to
describe capability requirements in terms of a sequence of operations.]
[ ‫ يجب أن تشكل البيانات الكمية التي تحدد سمات األداء والدقة جزءًا من مواصفات‬.‫ التي يحتاجها المستخدمون‬g‫تصف متطلبات القدرة الوظائف والعمليات‬
‫القدرة‬.
‫ القدرة من حيث تسلسل العمليات‬g‫ غالبًا ما يكون من المالئم وصف متطلبات‬.‫يمكن أن تكون أبعاد المكان والزمان مفيدة لتنظيم متطلبات القدرة‬.]
3.1.1 [subsection]
…
1R [id1]
[UR Statement]
Need [How essential is this UR]
Priority [Priority for incremental delivery]
Stability [How subject to change is this UR]
Source [Name of person, group, document, ... from which the UR originates]
Clarity [If more than one interpretation possible, this must be qualified]
Verifiability [Check that UR is incorporated into the design, is implemented in the software, and
can be tested]
[Any Other Attribute] [Value of any other attribute]
[‫]بيان دور المستخدم‬
]‫االحتياج [ما مدى أهمية دور المستخدم هذه‬
]‫األولوية [أولوية للتسليم المتزايد‬
]‫ قابلية التغيير في دور المستخدم هذا‬g‫االستقرار [مدى‬
]‫ الذي نشأ منه دور المستخدم‬... ، ‫ المستند‬، ‫ المجموعة‬، ‫المصدر [اسم الشخص‬
ً ‫ فيجب أن يكون هذا‬، ‫الوضوح [إذا كان هناك أكثر من تفسير واحد ممكن‬
]‫مقيدا‬
]‫ ويمكن اختبارها‬، ‫ وتنفيذها في البرنامج‬، ‫إمكانية التحقق [تحقق من إدراج دور المستخدم في التصميم‬
[‫]قيمة أي سمة أخرى[ ]أي سمة أخرى‬
1R [id2]
[UR Statement]
Verifiability [Check that UR is incorporated into the design, is implemented in the software, and
can be tested]
...
3.1.2 [ ... ]
…
3.2 Constraint requirements

[Constraint requirements place restrictions on how software can be built and operated. For example,
definitions of external communications, hardware and software interfaces may already exist, either because
the software is a part of a larger system, or because the user requires that certain protocols, standards,
computers, operating systems, library or kernel software be used.
Constraints that users may wish to place on the software include the quality attributes of adaptability,
availability, portability and security. The user shall describe the consequences of losses of availability, or
breaches of security, so that developers can fully appreciate the criticality of each function.
The user may choose to make additional standards applicable; such requirements are additional constraints
on the development. ]
ً ‫تضع متطلبات القيد‬
[ ‫ لالتصاالت الخارجية وواجهات األجهزة‬g‫ قد توجد بالفعل تعريفات‬، ‫ على سبيل المثال‬.‫قيود ا على كيفية إنشاء البرامج وتشغيلها‬
‫ أو معايير أو أجهزة كمبيوتر أو أنظمة تشغيل أو مكتبة أو‬g‫ أو ألن المستخدم يطلب استخدام بروتوكوالت‬، ‫ إما ألن البرنامج جزء من نظام أكبر‬، ‫والبرامج‬
‫ برامج نواة معينة‬.
‫ يجب على المستخدم أن‬.‫تشمل القيود التي قد يرغب المستخدمون في وضعها على البرنامج سمات جودة القدرة على التكيف والتوافر وقابلية النقل واألمان‬
‫ بحيث يمكن للمطورين تقدير مدى أهمية كل وظيفة بشكل كامل‬، ‫ األمان‬g‫ أو انتهاكات‬، ‫يصف عواقب فقدان التوافر‬.
‫ إضافية ؛ هذه المتطلبات هي قيود إضافية على التنمية‬g‫يجوز للمستخدم اختيار تطبيق معايير‬. ]
3.2.1 [subsection]
...
1R [id3]
[UR Statement]
Verifiability [Check how UR: can be incorporated into the design; implemented in the software;
can be tested]
[Any Other Attribute] [Value of Any Other Attribute]

[‫]بيان دور المستخدم‬
]‫االحتياج [ما مدى أهمية دور المستخدم هذه‬
]‫األولوية [أولوية للتسليم المتزايد‬
]‫ قابلية التغيير في دور المستخدم هذا‬g‫االستقرار [مدى‬
]‫ الذي نشأ منه دور المستخدم‬... ، ‫ المستند‬، ‫ المجموعة‬، ‫المصدر [اسم الشخص‬
ً ‫ فيجب أن يكون هذا‬، ‫الوضوح [إذا كان هناك أكثر من تفسير واحد ممكن‬
]‫مقيدا‬
]‫ في التصميم ؛ نفذت في البرنامج ؛ يمكن اختبارها‬:‫إمكانية التحقق [تحقق من كيفية إدراج دور المستخدم‬
[‫]قيمة أي سمة أخرى[ ]أي سمة أخرى‬
...
3.2.2 [subsection]
…
A [Appendix Heading]

Software Development Process The User Requirement Document Template

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Development Process The User Requirement Document Template

Uploaded by

Copyright:

Available Formats

Mobilefish.

com document SDP-MF-URD-0001

Software Development Process

name department date signature

1.0 3 Jul 2006 All First issue.

1.1 Purpose of the document

1.3 Definitions, acronyms and abbreviations

UML Unified Modelling Language

URD User requirements Document

From this Web page, access can be obtained to this document.

1.5 Overview of the document

2.1 General capabilities

2.2 General constraints

2.3 User characteristics

2.4 Operational environment

3.1 Capability Requirements

3.2 Constraint requirements

[Any Other Attribute] [Value of Any Other Attribute]

You might also like