it:ad:non-functional_requirements:localisation:home

IT:AD:Non-Functional Requirements:Localisation

Summary

Localisation is prohibitive to add at a later date: at the very least it affects caching, form layout (widths are different), requires more client side services, more server side endpoints, security considerations, database schemas, etc.

It's far cheaper to start development with Localisation in mind.

Requirements

<filter “Tags”=/Local/>

<dtable>

GUIDIDTagsStakeHoldersRequirement
{39E37BBB-6873-4970-BEC4-042A6D8CC84D}NFR:xxxxSupportRequirement:
Web sites MUST be configured to use a configurable different domain for static content.

Rational:
Every request, whether it be for the page, images on the page, css, or javascript, sends headers (including cookies), and processes cookies.

Recommendation:
Note that the requirement is of no benefit if the static domain is nested under the application domain.
Note that upon stakeholder agreement the static content domain parameter can be temporarily configured to be the same as the application domain.
{EB45447E-03CB-4538-9966-9D67DB4F1FC2}NFR-xxxxSupportRequirement:
IF a different domain is used for static content, the static domain MUST not be nested under the application domain.

Rational:
The recommendation of using a different domain for static content is ineffective if the static domain is nested under the application domain.

Recommendations:
The static content domain should be parralel to the application domain:
* myapp.static.corp.com
* myapp.corp.com

Acceptance Tests:
TBC| |{3F0B2E5F-376E-4332-B0DD-53F6C2C972FC}|NFR:xxxx||SHxxx|Requirement:
When releasing IIS based applications, the debug flag MUST be disabled in the site's web.config file.

Tags:
web,performance

Rational:

Increased memory footprint and unoptimized code are only two of the problems you'll see if the debug flag is set to true.

Resources:
Refer to ScottGu's blog explaining why:
 Article\\Read through the ASP.NET Performance Coding Architecture Guides (great book and also free).
{EAC87EC1-75A0-4029-B44E-AFB7E91A861A}NFR:8oyp7LocalisationSupportRequirement:
Changes to Resources (strings/images) SHOULD not require a redeployment of the system.

Rational:
URLs to external sites and documents (eg: PDFs, Spreadsheets) SHOULD be configurable application parameters. But if this is not the case, and the url (or other text) is actually embedded in a View resource, the change should be able to be applied by technical support personnel without requiring a full deployment.

Recommendation:
Use a ResourceManagementService to allow the editing of Resources, which are persisted to a datastore.
{C39037AB-05F8-4576-8A0D-394C5B579888}NFR:8oyp8Localisation,Accessibility,ComplianceUsersRequirement:
New development MUST persist user presented text and images in resource catalogs.

Rational:
The least costly way to reach more users is to allow more languages.
In addition, allowing more than one language is sometimes required for Compliance reasons.
{8E8E35BC-D336-4b86-8D5F-01A8645E3C06}NFR:8oyp9LocalisationDevelopersRequirements:
Resources MUST allow localization of strings.

Rational:
The primary resource type that can be localized is UI text for labels, instructions, copy.
{DE9C918D-D107-44fa-BDF9-FFEB9DD2E404}NFR:8oypbLocalizationBusiness,DevelopersRequirements:
The resource service chosen for the solution SHOULD be able to localize images.

Rational:
Logos and other images can include text.

Recommendation:
Use a ResourceService that can retrieve images localized according to the user agent's culture/region information.
{xxx}NFR:8oypaLocalisationDevelopersRequirement:
Resources MUST be searched for the first match in the following order: Culture:-Region:, to Culture: – and if not found, dropping back to UniversalCulture.

Rational:
this mirrors how Windows does it.
{xxx}NFR:8oeosUsability,Data Quality,Validation,FormsUserRequirement:
Form View Models MUST be validated as per: Validation
{xxx}NFR:8oeosUsability,Data Quality,Validation,FormsUserRequirement:
Form View Models SHOULD be validated as per: Validation
{xxx}NFR:8oeh1Usability,Data Quality,Validation,FormsUserRequirement:
Field validation SHOULD be performed after every keystroke (“real-time validation”)
{xxx}NFR:8oeotUsability,Data Quality,Validation,FormsUserRequirement:
“real time field validation” SHOULD be skipped while the View form field contains less than 2 characters.
{xxx}NFR:XxxxUsability,Data Quality,Validation,FormsUserRequirement:
Client side Form View field validation should be processed upon field exit/loss of focus.
Value='' when Required=true: processed when lost focus.
{xxx}NFR:8oeh9Usability,Data Quality,Validation,FormsUserRequirement:
Client side real time validation SHOULD NOT be processed upon the View load event.

Rational:
when loading existing records that do not validate, users should not have to look at an error prior to any data changes on their part.
Some View form fields (eg: Name fields) should only Validated upon loss of focus, which would be after view form load.
{xxx}NFR:8okr2UXSHxxxRequirement:
Design each new Interface (ie, Web Page) as an assembly of Views.

Rational:

Resources:\\New user interfaces MUST be development as Views, not Pages.
{xxx}NFR:8oi04UXSHxxxRequirement:
Views MUST be designed around a single desired Action.

Rational:
This promotes better completion of Actions, as well as improves maintainability of the code as it adheres better to the pattern of Separation of Concerns (SOC).
See: IT:AD:Patterns:Views are not Screens Strategy
Pages can be assembled from tree composition of Views (HeaderView (LogoView, UserInfoView, HeaderMenuView), SomeFormView, FooterView).
Pages can be developed by adding/removing/hiding/replacing Views depending on the limits of the platform they are being rendered on (mobile screens are smaller than desktop screens, and may not need everything displayed to still be Actionable.
{xxx}NFR:8okr3UX,UsabilitySHxxxRequirement:
Each Interface (eg: a single web page) MUST have a Primary View.

Details:
 The primary view MAY optionally supported by surrounding supporting Views (HeaderView (itself composed of LogoView, UserView, HeaderMenuView), FooterView, etc.).

Resources:
Ensure these supporting Views help bring meaning towards it, rather than distract away from that.
Clarity of purpose leads to completion of Action.
{xxx}NFR:8okr3UX,Understandability,MaintainabilitySHxxxRequirement:
A View MUST either be an Input or an Output View, but not both.

Rational:
Clearly separating input from output makes for clarity to purpose and determination of the View's primary Action.
Additionally, it makes for more maintainable code.

Information:
View Types come in many forms:
* Output:
* Message (OK button only – but can be on page directly)
* ReportView (non-editable view)
* Input:
* Choice (Multiple buttons, or Radio + Button)
* EditableForm (editable view)
* DynamicallyEditableForm (fields switch between readonly/editable depending on other field values)
* SelectableList (bullet list, etc)
* SelectableEditableList (bullet list, etc)
* SelectableGrid (Provide “Selected” Property, but are not editable)
* SelectableEditableGrid (Provide “Selected” Property, and are editable)
{xxx}NFR:8oj66UXSHxxxRequirement:
A View SHOULD have only one primary Action (see [NFR:8oeum]), with any secondary Actions rendered less prominently.

Rational:

Resources:
In Web applications, the primary Action is normally rendered as a button, the secondary Actions ('Cancel', etc.) rendered as web links.
{xxx}NFR:8sqzuAccessibilitySHxxxRequirement:
To help low-visibility users better understand a page's intent, prefer 'single message pages'

Rational:
By displaying less, screen readers have less to read aloud, and therefore the user has to listen to less before he or she gets to the part that is of import to them.
{xxx}NFR:8oerzAccessibilitySHxxxRequirement:
User interface colors MUST NOT use red/green for success/failure (use red/blue).

Rational:
there are primarily two kinds of colour blindness: Red/Green: (1 out of 5), and Blue/Yellow (rarer 1) – hence why Red/Blue always works.
{xxx}NFR:8oet0CxxxSHxxxRequirement:
Icons SHOULD be distinguishable by shape AND colour.

Rational:
Two glossy pill buttons, one red, one green, are difficult for a red/green colour-impaired person to distinguish between, whereas an X on a red background is distinguishable from a tick mark on a blue background.
{xxx}NFR:8oet2CxxxSHxxxRequirement:
icons graphics SHOULD be simple black outlines that can be overlaid over colour backgrounds.

Rational:
icons should be distinguishable by shape alone by colour-impaired users.

Information:
See [NFR:8oet0].
Prefer 'flat' b/w icon diagrams on flat coloured backgrounds, in contrast to the very detailed icons of the turn of the century. Colour impaired users have difficulty determining the boundary between some of the colours used (red/green or blue/yellow) within the little pictures of printers, etc.
{xxx}NFR:8oeumUsabilitySHxxxRequirement:
When presenting Action options, recommend one, rather than offering equal choice.

Rational:
users take longer to weigh options when all options are presented equally.

Information:
The more choice, the less decisions made (see study by Sheena Iyengar).
see NFR:8oku0:.

Resources:
* http://goodui.org/#7
* NY Times * Wikipedia
{xxx}NFR:8oku0UsabilitySHxxxRequirement:
Remove dual primary Actions.

Rational:

Information:
See 8oeum
Consider a website that proposes the following Actions: 'Signup','Buy', 'Contact Us'. It's confusing as to what Action was the intent of the View (“Should I Contact the company before I make a decision to Buy? And what exactly is the difference between Signup and Buy?”). Remove Buy for now, put it later. Remove Contact Us until they've signed up. Maybe Buy as well, showing it only to logged in users who previously signed up.
{xxx}NFR:8ohyqUsabilitySHxxxRequirement:
When designing View layouts, remove clutter, improving clarity of purpose of View.

Rational:
removing confusion leads to Action completion.
{xxx}NFR:8oizyCxxxSHxxxRequirement:
Form Views should offer an option to Undo Actions rather than a modal Confirmation query.

Rational:
Undos respect the initial human intent by allowing the action to happen smoothly first and foremost. Prompts on the other hand suggest to the user that he or she does not know what they are doing by questioning their intent at all times – a dehumanizing experience.\\Information:
See: [NFR:8oj1a].
{xxx}NFR:8oj6qUsabilitySHxxxRequirement:
Avoid Modal Prompts.

Rational:
Modal dialogs can be classified as Flow Stumbling Blocks: a Modal Alert forcibly remove Focus from the task the User was working on, to deal with an overlay (an alternate View and primary Action) and then forces the user to relocate the original field they were working on in the original View, in order to try to comply with the instructions that were in the modal dialog View, that is no longer visible.
{xxx}NFR:8oj15UsabilitySHxxxRequirement:
Use fewer form fields

Rational:
users inherently resist labor intensive tasks as well as disclosing information.
Additionally, not everyone types at the same speed, while typing on mobile devices is still a chore in general. Each additional field runs the risk of the user giving up 2).
This mainly applies to commercial sites looking for higher conversions, but applies in LOB as well, diminishing the homogeneity of data entered, with some entries having the minimum fields entered, others more.
See [NFR:8oj16].
{xxx}NFR:8oj16UsabilitySHxxxRequirement:
Attract Newcomers, Engage Experts, with Progressive Disclosure.

Resources:
3)
{xxx}NFR:8oj19UsabilitySHxxxRequirement:
Consider carefully the verbs used for Actions, in relationship to the prompt text chosen.

Rational:
clarity of Action leads to more Completion of Actions.
{xxx}NFR:8oj1aUsabilitySHxxxRequirement:
If the Action is not undoable, there is maybe still a valid use for Modal Dialogs.

Resources:
See: http://ux.stackexchange.com/questions/9946/should-i-use-yes-no-or-ok-cancel-on-my-message-box.
See [NFR:8oizy]
{xxx}NFR:8oj7nUsabilitySHxxxRequirement:
When designing pages, remove before adding

Rational:

Rational:
removing clutter, promoting a single Action, increases Action completion.

Information:
Subtraction is harder than Adding. So Start with adding nothing, and if you can't get away with that, add only one thing. Then try to remove it again.
See [NFR:8ohyq].
{xxx}NFR:8oj99UsabilitySHxxxRequirement:
Design your layout for infinit screens.

Rational:
There is no standard website page any longer4). Not only are desktop screens dimensions all over the place these days (common to see anything between 14“ to 24”), but dpi also comes in to play.
Dpi is no longer fixed at 96dpi, but with the iPad and later is over 300dpi making 1024“ be only 3.5” wide.
* There was a while where they were trying to sell the moniker of 3 screens and a cloud (computer, tv, mobile) – but that only lasted a season before it became pretty obvious that 3 wasn't enough (computer, tv, mobile, watch, fridge, handband, etc).
* The point is – don't design pages with static layout. Documentation/FRD's containing wireframes are meaningless these days – you can only work with a design of Views, that flow into various layouts depending on the screen on which they are being presented.
{xxx}NFR:8oj7mUsabilitySHxxxRequirement:
Review your copy regularly.

Rational:
Over time, entropy is caused by unintentionally creating multiple sections, elements and features which all perform the same function, potentially with slightly different labelling. Repetition not only dulls the message, but slight differences in labelling sstrains customers trying to understand if messages are the same or not, increases the learning curve, diminishing conversion5).
{xxx}NFR:8oj7zUsabilitySHxxxRequirement:
Views SHOULD be Single Column.

Rational:
a one column layout will give you more control over your narrative. It should be able to guide your readers in a more predictable way from top to bottom. A multi column approach runs the risk of being distracting to the core purpose of a page.
{xxx}NFR:8oj7zUsabilitySHxxxRequirement:
Each view's copy SHOULD guide people with a story and a prominent call to action at the end.
{xxx}NFR:8okxhUsabilitySHxxxRequirement:
Each view's copy SHOULD be Affirmative, not Questioning.

Resources:
If you're ending your messaging with question marks, using terms such as “perhaps”, “maybe”, “interested?” and “want to?”, then most likely you have some opportunity to be a bit more authoritative.
See: http://goodui.org/#10
{xxx}NFR:8okxiUsabilitySHxxxRequirement:
Each view's copy SHOULD uses single Action terms.

Rational:
A call to action should clearly tell users what you want them to do..
Examples are: Call, SignUp, Register, Subscribe, Buy, Donate, Enjoy, Try, etc.

Resources:
[NFR:8oku0]
http://boagworld.com/design/10-techniques-for-an-effective-call-to-action/
{xxx}NFR:8okxjUsabilitySHxxxRequirement:
Consider using urgency in your copy to promote Action completion now rather than later.

Resources:
Examples are “Offer expires March 31st”, “For a short time only”, “Order before the end of the week and receive a free gift”.

Resources:
http://boagworld.com/design/10-techniques-for-an-effective-call-to-action/
{xxx}NFR:8okxkUsabilitySHxxxRequirement:
View text SHOULD implement Generosity unconsciously begets reciprocity.

Rational:
The most important part of a commercial website is the purchase button, with the whole rest of the website persuading the user to Action it.
That said, avoid plastering your website with “Buy! Buy! Buy!”.
Instead, offer a free sign up period or similar gift rather than trying to close the deal straight away.
A friendly gesture - gifting - is an effective persuasion tactic based on the rule of reciprocity.
As obvious as it sounds, being nice to someone can come back in your favour down the road.

Resources:
http://goodui.org/#2
{xxx}NFR:8okxlUsabilitySHxxxRequirement:
Requirement:
View text SHOULD make gifts count.

Rational:
To complete a call to Action, you sometimes have to sweeten the deal (giving away discounts, entry into a competition, a free gift, a t-shirt, etc.
Not all gifts are equal.
Consider Obama's website where if you made a donation of $30 or more you got a free t-shirt. The beauty of it is that the gift made the user into a walking advertising billboard.		Resources:
Call to Action
{xxx}NFR:8okxmUsabilitySHxxxRequirement:
View text MUST not talk about your organisation or features – choose others to do it for you – use Social Proof rather than talking about yourself.

Rational:
seeing endorsements by others is a great persuasion tactic.\\Information:
There is plenty of data that shows usage by others is a strong call to action.

Resources:
http://goodui.org/#4
{xxx}NFR:8okxnUsabilitySHxxxRequirement:
View text SHOULD have unmissable “calls to action”.

Rational:

Resources:
Make it Centered,Big,Bright, Contrasted in colour to the backgroud.
In addition, use white space around it to bring attention to the message.
{xxx}REQ-xxxxMaintainabilitySHxxxRequirement:
The system SHOULD be developed using Message Codes rather than Message Text.

Rational:
codes are less resource intensive, as well as allow culture specific translation.
{xxx}NFR:8oxvtMaintainabilityDevelopersRequirement:
Each form field SHOULD have 3 texts associated to it: 'label' (eg:'Email'), 'hint/ghost text'('Your email address'), and 'help'.
{xxx}NFR:xxxxInterfaces,API,DocumentationSHxxxRequirement:
APIs must be versioned.

Rational:
APIs are public access to the application, that if useful, will grow, and therefore change.
Information:

Resources:
{xxx}NFR:xxxxInterfaces,APISHxxxRequirement:
API Services and Operations should be specifically named.

Rational:
This is so that any code refactoring in the future do not inadvertently break public contracts that clients rely on.
Information:

Resources:
{xxx}NFR:xxxxInterfaces,APISHxxxRequirement:
In .NET WCF, one uses the [DataMember(Name=“Foo”)] directive.

Rational:
This is to ensure the method is published as Foo regardless of what the code method is renamed to.

Information:
Other frameworks have different mechanisms, but most mature ones allow for this precaution to be applied.

Resources:
{xxx}NFR:8ny7yInterfaces,API,DocumentationSHxxxRequirement:
The documentation for public facing APIs must declared support end date.

Rational:
Allows for upgrading your software without having to keep stale api's working for an indefinite amount of time.
Information: \\if no end date is specified, it implies that the service will be kept in perpetuity, and that client's don't have to move to later versions. The maintaining of current and legacy methods can have large impacts on maintenance costs.
A stated end date does not mean the service will automatically be terminated: if there is not a later API to move to, it will continue to function.

Resources:
{xxx}NFR:8p1ujInterfaces,API,DocumentationSHxxxRequirement:
The documentation for public facing APIs must indicate clearly that any cookies required (eg: Session Cookies) are not to be accessed by name, but pked up as a whole collection of domain cookies, whatever their name, and re-attached to the next request.

Rational:
different security providers may use different cookie names to track sessions. Changing provider in the future, in order to provide better security – or any other reason – should not impact client software.
Information: \\there is no reason that a client should be working with the contents of a session cookie (they cannot read the contents). They don't control its duration either (it's Session based). It's just a cookie they have to round-trip. If they are not investigating it, they should just pick it up as part of a collection, without inspecting the collection, and round-trip the cookie.

Resources:
{xxx}NFR:8qyhqInterfaces,API,DocumentationSHxxxRequirement:
The documentation of the public facing API must indicate clearly that the text of returned messages is not fixed, and may be changed at any time.

Rational:
the message of a text should be able to be updated as needed to be made failure reasons clearer – or some parts removed for security reasons.
Information:

Resources:
{xxx}NFR:8qyhrInterfaces,API,DocumentationSHxxxRequirement:
The documentation for any public facing APIs must indicate clearly that client systems and user agents must use only the returned Message Code/Number to determine the next sequence, not the Message Text.

Rational:
as per [NFS:8qyhq] messages can be updated at any time.
Information:
In multi-cultural applications, the text returned will be in a different language, depending on the User-Agent's request parameters.

Resources:
{xxx}NFR:xxxxValidationDevelopersRequirement:
Input text fields MUST used for searches (eg: 'Name') for Word quote and apostrophes, and replace them with ASCII quote and apostrophe.

Resources:
This is especially important if the data is round-tripped as a service, potentially leading to data-duplication due to not being able to match on certain characters.

Rational:
The original system may not have Validation that prevented the saving text cut/pasted from Word documents.
If this is not done, Sql Serve and most other databases will think that O'Neil is not the same as O'Neil.

Resources:
{xxx}NFR:xxxxData Migration,Validation,MaintainabilitySHxxxRequirement:
A choice of line feeds MUST be defined, and both migrated data and validation rules comformed to the decision.

Details:
Determine the impact of having different line feed characters (\n or \r\n) and decide whether search/replacement is required.

Rational:

Resources:
{xxx}NFR:xxxxData Migration,MaintainabilitySHxxxRequirement:
Text SHOULD be converted to Markdown or similar format.

Details:

Rational:
For data longevity and reusability. Resources:
{xxx}NFR:xxxxData Migration,Data QualitySHxxxRequirement:
Data Migration operations MUST be developed separately from Data Quality operations.

Rational:
DataQuality operations are endless in scope and cannot be used to track progress. This is especially when working with constantly updated live data as source.
Information:
Refer to the Helios project as an example of what not to do.

Resources:
{xxx}NFR:xxxxData StorageSHxxxRequirement:
Primary Keys MUST not be created from natural keys.

Rational:
The Primary Key is a data store artefact.
{xxx}NFR:xxxxData StorageSHxxxRequirement:
Records MUST not be deleted.

Rational:
Auditing depends on knowing the state of records not as they are, but as they were. Relationality is still required. Additionally, deleted records cannot be used to restore the record to a previous state, as per an undo Undo strategy.
Information: An example of why it is of great value is an accounting system that keeps track of transactions, referencing product Items as they were on the day of the transacation – not as they are now.
{xxx}NFR:xxxxData StorageSHxxxRequirement:
Records MUST be 'soft-deleted' using a nullable UTC based DateTime flag.

Rational:
A datetime provides sequence information, providing information necessary for a multiple step undo/redo mechanism.
Defintions:
* soft-deleted: records are not actually deleted from the database, but logically deleted using a Deleted flag of some kind.
{xxx}NFR:xxxxData StorageSHxxxRequirement:
Records MUST be 'soft-deleted' using a change of State, and a nullable UTC based DateTime flag.

Rational:
A change of state allows for workflows of changing Records from Active to Trash to Deleted. The datetime provides information required to restore sequence information, providing information necessary for a multiple step undo/redo mechanism.
{xxx}NFR:xxxxData StorageSHxxxRequirement:
Primary Keys MUST be Data access layer generated GUIDs.

Details:

Rational:
GUIDs allow for synchronization across environments and devices.

Information:
Int Ids cannot be synchronized.
The use of data access layer generation of GUIDs allows for Clients to generate Primary Keys while offline, disconnected from a server based database.
Note also that when solutions implement an Undo/Redo architecture based on adding/removing records from a data store table, GUIDs allow the re-insertion of deleted records, whereas integer Ids generated by the database do not.

Resources:
{xxx}NFR:8rjy6Data StorageSHxxxRequirement:
Primary Keys MUST be data access generated Sequential GUIDs.

Details:
Sequential GUIDs are based on the UTC timestamp + a random element.

Rational:
Sequential GUIDs allow for vastly faster record insertions and indexing than random GUIDs.

Information:
Note that a sequential Guid allows for the creation of GUIDs in various client languages, including Javascript, C#, etc.
Important:
Sql Server's database SEQUENTIALID function MUST not be used.

Resources:
{xxx}NFR:8rjy5Data StorageSHxxxRequirement:
Stored Procs SHOULD not be used.

Details:

Rational:
Application logic should remain in the Application layer, not the Data layer.

Information:
Stored procs are not portable, and not available on SqlServer CE, and therefore make Automated Tests more difficult.

Resources:
{xxx}NFR:8rjy4Data StorageSHxxxRequirement:

Details:
Time MUST be stored in UTC DateTime format.

Rational:
Using UTC datetime allows the application to be hosted in the cloud, in different locals.
Storing dates in UTC removes common conversion bugs.

Information:
At no extra cost it makes the application usable from anywhere in the world, including Mobile.

Resources:
{xxx}NFR:xxxxData StorageSHxxxRequirement:

Details:

Rational:

Resources:
{xxx}NFR:xxxxData StorageSHxxx
{xxx}NFR:xxxxData StorageSHxxxRequirement:
The creation, modification and deletion of records MUST be audited.

Rational:
Obvious.
{xxx}NFR:xxxxData StorageSHxxxRequirement:
Operation audit records MUST be persisted in a untamperable manner.

Rational:
Obvious.
Information: a common process involves the use of cryptographic signage of a hash of the rest of Audit records data.
{xxx}NFR:xxxxData Storage,CodeFirstSHxxxRequirement:
CodeFirst MUST be used to release Application specific Schema changes.

Rational:
The application knows best what database schema it requires. Introducing a separate process will lead to a disparity between the two.
Details:
These include table structure, indexes, constraints. \\Information:

Resources:
{xxx}NFR:xxxxData Storage,CodeFirstSHxxxRequirement:
CodeFirst Migrations MUST not be used to produce Tables, Views, Indexes, etc. that are not needed by the application, but by different applications that require access to the same table.

Rational:
Separation of Concerns directs one to let the app only handle what the app needs – and the other application's requirements be handled by a different process.
Information: \\There are so many reasons to never let another access the application's database directly, that the above should never be an issue. Prefer providing a Data Service to provide the information in a controlled manner.

Resources:
{xxx}NFR:xxxxDocumentationSHxxxRequirement:
Documentation MUST include a glossary of the business Domain's Vocabulary.

Rational:
Good design is coherent, developing from the same symbols.
Information:

Resources:
{xxx}NFR:xxxxDocumentationSHxxxRequirement:
Documentation MUST prefer Brevity.

Rational:
Waffle is a indication of not having the Vocabulary to describe the problem, and solution.
Information:

Resources:
{xxx}NFR:xxxxDocumentationSHxxxRequirement:
Documentation SHOULD prefer Indended Bullet points over Tables.

Rational:
Bullets allow n Attributes, whereas the width of paper tends to lead to a preference of having only a subset of the Attributes – those that fit in the page.
Information:

Resources:
{xxx}TFR:8ruxpMaintainabilityDevelopersRequirement:
The solution name MUST follow a ClientName.ProjectName convention (eg: Corp.Thing.sln)

Rational:

Information:

Resources:
{xxx}TFR:8ruxqMaintainabilityDevelopersRequirement:
Project names within the Solution MUST have no reference to either the Client or Project names, and just have an 'App.' prefix.

Rational:
Using WellKnown names that are not specific to a single application promotes the reuse of supporting scripts, documents and procedures. These supporting artifacts are expensive to produce.
Information: \\Project names are not the same as the Assembly name: the Assembly name can be set from the Properties tab, without interfering with script and document text reuse.
Rational:as much code that can be re-used is more valuable to the end client.

Resources:
{xxx}TFR:8ruxsMaintainabilityDevelopers,SupportersRequirement:
Semantic Versioning SHOULD be used for the entry point assemblies.

Rational:

Information:

Resources:
{xxx}TFR:8ruxtMaintainabilitySHxxxRequirement:
Versioning MUST be limited to only the entry point assemblies.

Rational:

Information:
Supporting assemblies are packaged with the Entry point assemblies. There is no strong benefit to Versioning supporting assemblies, as it will always be the version number of the Entry point assembly that is checked.
See [TFR:8ruxs]

Resources:
{xxx}TFR:8ruxrMaintainabilityDevelopersRequirement:
Namespaces within the solution – excluding those wrapping publicly shared classes – MUST have no reference to the Client or Project names, and just start with an 'App.' prefix.

Rational:
Using WellKnown namespaces that are not specific to a single project promote the reuse of supporting scripts, documents, and procedures. These supporting artifacts are expensive to produce: maximizing reuse is cost-effective.
Information:

Resources:

</dtable>

</filter>

1)
http://www.color-blindness.com/2006/04/28/colorblind-population/
2)
http://goodui.org/#13
3)
http://ryanhanau.com/book/google-ux-design-principles
4)
http://stackoverflow.com/questions/10538599/default-web-page-width-1024px-or-980px
5)
http://goodui.org/#3
  • /home/skysigal/public_html/data/pages/it/ad/non-functional_requirements/localisation/home.txt
  • Last modified: 2023/11/04 01:51
  • by 127.0.0.1